<birtles> [11] Expose animateMotion values in the SVG DOM

<birtles> birtles: is it not exposed in the animated value of the transformed list?

<birtles> all: no it's not

<birtles> krit: shouldn't it be exposed through the OM for CSS Transforms?

<birtles> shanestephens_: it would be better if you can query the animated value per animation effect not just the composite result

<birtles> heycam: yeah, that would be nice

<birtles> shanestephens_: we can add an API for that in Web Animations

<birtles> heycam: let's leave it to Web Animations then

<birtles> krit: what about adding a new layer/stylesheet for animation to the cascade?

<birtles> ... it would need to be defined by Web Animations

<birtles> heycam: let's drop it from the requirements list and leave it to Web Animations

<birtles> [12] Make the SVG*List interfaces a bit more like other lists/arrays

<birtles> ed: I think heycam did it

<birtles> heycam: I think I did it when I converted the interfaces to Web IDL

<birtles> ... I guess it's done

<birtles> [13] Make it easier to read and write to attributes in the SVG DOM

<birtles> AlexD: I think the proposal for rect.x.px is nice for developers

<birtles> heycam: it would be pretty easy to add just that

<birtles> ... so should we just do that?

<birtles> all: seems good

<birtles> heycam: should it be base val or a hybrid of anim/base val?

<birtles> all: seems better to just use base val

<birtles> ACTION: Cameron to add length shortcuts to SVG DOM [recorded in http://www.w3.org/2013/02/04-svg-minutes.html#action01]

<trackbot> Created ACTION-3414 - Add length shortcuts to SVG DOM [on Cameron McCormack - due 2013-02-11].

<birtles> heycam: how would you represent calc() etc. in the DOM?

<birtles> ... do you just have to use the CSSOM for that?

<birtles> krit: let's talk about that as part of the CSSOM discussion

<birtles> [14] Improve the SVG path DOM APIs

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM#Making_Improvements

<birtles> birtles: I made a proposal about creating paths from an array of floats

<birtles> ... it would also be neat to have some constructors for some of the path data types

<birtles> heycam: what about extending the existing methods but allowing them to take a string instead

<birtles> ... let's keep the requirement for now

<birtles> ... we'll go into it when we talk about canvas path proposal later

<birtles> [15] Ensure improved property value access to SVG properties

<birtles> ... CSSOM will fix this, skip it

<birtles> [16] Improve bounding box method APIs

<birtles> [We think we have already added this to the spec, but there is some discussion related to this later in the week.]

<birtles> ... keep it

<birtles> [17] Have a method for <image> to select a part of an image to display, maybe by allowing viewBox on it

<birtles> AlexD: good for DOM spriting

<birtles> heycam: you can do this with media fragments

<birtles> ... do we need a separate feature for this?

<birtles> krit: does that apply to <image> elements too?

<birtles> ... we need to add spec text for that (supporting image fragments)

<birtles> ... and then we run into trouble with SVG sprites etc.

<birtles> heycam: I thought we resolved that

<birtles> krit: we only resolved that for CSS, not for SVG

<birtles> ... (i.e. CSS properties, not xlink:href)

<birtles> ... we need to define how <image> interacts with media fragments

<birtles> [Added to agenda]

<birtles> [18] Allow auto-sized images

<birtles> heycam: no progress there

<birtles> ... it's to do with adding "auto" to <image> element's width and height

<birtles> ... I think we decided they should default to zero

<birtles> ... but it's yet to be added to the spec

<birtles> ... the only issue remaining is just how to reflect auto in SVGLength

<birtles> ... we could just use UNKNOWN

<birtles> ... like we do for transforms

<birtles> krit: but then what would you do for, e.g., <rect>

<birtles> ... since it uses the same property

<birtles> ... you would have to define what it means to have a <rect> whose width is "auto"

<birtles> heycam: we could just make it zero (the initial value)

<birtles> ... let's keep this one

<birtles> ACTION: Cameron to spec auto-sized images [recorded in http://www.w3.org/2013/02/04-svg-minutes.html#action02]

<trackbot> Created ACTION-3415 - Spec auto-sized images [on Cameron McCormack - due 2013-02-11].

<birtles> [19] Support level of detail control

<birtles> birtles: will be covered tomorrow when we discuss <iframe> for SVG

<birtles> heycam: let's keep the requirement for now

<birtles> [20] Be able to display InkML trace groups by some means such as buffered-rendering and variable stroke width , not necessarily varying anything

<birtles> heycam: this is basically variable stroke-width

<birtles> ... which we will discuss later

<birtles> birtles: there's also buffered rendering

<birtles> heycam: which ed already added to the spec

<birtles> [21] Allow transform on the <svg> element

<birtles> ed: done right?

<birtles> krit: yes, since you added <svg> to SVGGraphicsElement

<birtles> ... but we need to specify what happens on the root element

<birtles> ... but CSS Transforms is not supposed to apply to the root element I think...

<birtles> heycam: but what if you apply CSS transforms to the <html> element?

<birtles> krit: I think that should work actually...

<birtles> heycam: I think root <svg> should do that same as <html>

<birtles> ed: I agree

<birtles> ACTION: Dirk to investigate applying CSS transforms to SVG when it is the root element of the document [recorded in http://www.w3.org/2013/02/04-svg-minutes.html#action03]

<trackbot> Created ACTION-3416 - Investigate applying CSS transforms to SVG when it is the root element of the document [on Dirk Schulze - due 2013-02-11].

<birtles> heycam: we need to specify the order in which the transform applies in relation to the viewBox etc.

<birtles> krit: yes, we need to define where it applies

<birtles> RESOLUTION: transforms should apply at the beginning of the transform cascade (as if the transform applied to a group around the <svg> element)

<birtles> [22] Support a mechanism like or the same as allowReorder from SMIL3

<birtles> heycam: still needs to be done

<birtles> ... it would be an easy one to add if someone wants to do it

<birtles> ... if no one wants to add it, skip it for now

<Cyril> http://www.w3.org/Graphics/SVG/WG/track/issues/2238

<birtles> [23] Relax referencing requirements to particular elements to allow dropping fragments to mean referencing root element, where it makes sense, such as with use

<birtles> heycam: makes sense

<birtles> ACTION: Cameron to relax referencing requirements (issue-2295) [recorded in http://www.w3.org/2013/02/04-svg-minutes.html#action04]

<trackbot> Created ACTION-3417 - Relax referencing requirements (issue-2295) [on Cameron McCormack - due 2013-02-11].

<birtles> [24] Normatively reference the SVG Parameters spec

<birtles> heycam: we need to resolve how this interacts with CSS variables before we references it

<birtles> krit: so, not now?

<birtles> ... I don't think we have an editor for it now

<birtles> heycam: so let's not normatively reference it until it's ready

<birtles> [25] Add data-* attributes to align with HTML5

<birtles> heycam: I think we should do that

<birtles> ... might need coordination if it's defined on HTMLElement

<birtles> ... so we can reference it

<birtles> ... it's currently on HTMLElement

<birtles> krit: we could add it to Element

<birtles> ed: where should we add it? SVGElement or Element?

<birtles> heycam: someone should send a mail to whatwg list regarding moving data to Element

<birtles> ACTION: Cameron to mail HTML people about moving data to Element [recorded in http://www.w3.org/2013/02/04-svg-minutes.html#action05]

<trackbot> Created ACTION-3418 - Mail HTML people about moving data to Element [on Cameron McCormack - due 2013-02-11].

<birtles> [26] Align with HTML5 global semantic attributes where these make sense for SVG

<birtles> [this is things about microdata]

<heycam> http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#global-attributes

<birtles> [Discussion about classList being on Element and issues around className]

<birtles> heycam: let's discuss the specific attributes later but keep the requirement for aligning with HTML here

<birtles> ACTION: Cameron to follow-up aligning with global HTML attributes in SVG [recorded in http://www.w3.org/2013/02/04-svg-minutes.html#action06]

<trackbot> Created ACTION-3419 - Follow-up aligning with global HTML attributes in SVG [on Cameron McCormack - due 2013-02-11].

<birtles> [27] Make property values case insensitive

<birtles> heycam: I think we should have this one

<birtles> ... this is just about presentation attributes

<birtles> ... they are currently case-sensitive but they shouldn't be

<birtles> [Discussion about camel case attribute names and the CSSOM]

<birtles> [28] Add color management subject to deciding the exact conformance classes required

<birtles> heycam: chris has already done a bunch of changes here

<birtles> [29] Include non-scaling stroke

<birtles> ed: it's implemented but not in the spec yet

<birtles> ACTION: Erik to add non-scaling stroke to SVG2 [recorded in http://www.w3.org/2013/02/04-svg-minutes.html#action07]

<trackbot> Created ACTION-3420 - Add non-scaling stroke to SVG2 [on Erik Dahlström - due 2013-02-11].

<birtles> [30] Include non-scaling features (non-scaling part of the object, and non-scaling entire object)

<birtles> birtles: we will cover this on Wed morning

<birtles> [31] Include a way to specify stroke-position

<birtles> heycam: a few years ago I presented a proposal for this

<birtles> ... do we still want this?

<birtles> [Discussion about implementation strategies]

<birtles> birtles: could we defer to SVG3?

<birtles> all: agreed to defer this requirement to SVG3

<birtles> [33] Allow more author control over positions of dashes

<birtles> [32] Specify more precisely stroke dashing

<birtles> heycam: done

<birtles> ... I added wording for this

<birtles> [33] Allow more author control over positions of dashes

<birtles> heycam: would be nice, but I can do without it

<birtles> ed: what kind of control

<birtles> heycam: e.g. stretching dash to corners etc.

<birtles> ACTION: Cameron to add dash control to SVG2 [recorded in http://www.w3.org/2013/02/04-svg-minutes.html#action08]

<trackbot> Created ACTION-3421 - Add dash control to SVG2 [on Cameron McCormack - due 2013-02-11].

<birtles> [34] Support hatching without the artefacts that patterns currently impose

<heycam> Tav, are you still on track to adding the hatching proposal to SVG 2?

<heycam> Tav, I think people here are keen for it to go in

<birtles> heycam: we'll assume Tav is taking care of this

<birtles> [35] Support custom filters

<birtles> krit: it's in Filter Effects

<birtles> heycam: we can just reference that

<birtles> [36] Align the style element with the HTML 5 style element

<birtles> heycam: I already have an action for this

<birtles> ... it's about adding scoped etc.

<birtles> AlexD: what about href?

<birtles> ... that's pretty painful

<birtles> heycam: we decided to drop xlink from href everywhere

<shepazu> (not just href… all xlink elements, like title, etc.)

<birtles> AlexD: HTML uses src and this is a real pain point for developers

<birtles> heycam: we should just use 'src' in SVG's style element too

<birtles> heycam: so we decided <image> would allow 'xlink:href', 'href' AND 'src'?

<birtles> [seems so, but which one wins?]

<birtles> nikos: there was some discussion at rigi about that

<birtles> heycam: details, we can work that out later

<birtles> [37] Include better bounding-box querying functions

<birtles> dupe, skip

<birtles> [38] Ensure there is a way to specify rotations around particular points and shapes

<birtles> heycam: this may be fixed by transform-origin?

<birtles> Dmitry: I want to rotate two elements around a point together (even though they may already have other rotation)

<birtles> krit: we could make transform-origin a list in the future

<birtles> Dmitry: we also need an origin for scale

<birtles> krit: we could also solve this with a list for transform-origin

<birtles> [This will be resolved in CSS Transforms]

<birtles> [39] Support shared path segments

<birtles> shanestephens_: this would be handy for animation

<birtles> cabanier: I thought we already deferred this

<birtles> ACTION: Cyril to specify shared-path segments [recorded in http://www.w3.org/2013/02/04-svg-minutes.html#action09]

<trackbot> Created ACTION-3422 - Specify shared-path segments [on Cyril Concolato - due 2013-02-11].

<birtles> [40] Include the smooth path between points functionality (Catmull-Rom)

<heycam> shepazu, are you still OK to be assigned to add the catmull-rom stuff to the spec?

<birtles> Dmitry: it's very popular amongst developers

<birtles> birtles: I think the only outstanding issue was the tension property

<birtles> heycam: I'd like to have it as well

<shepazu> heycam, yes, unless someone else wants to do it

<heycam> shepazu, yes no problem; we're just trying to remove things from the list that aren't realistically going to get done, but if it's still on your radar that's fine

<nikos> scribenick: nikos

Marker knockouts using masking or compositing

heycam: I put some half baked proposal into the spec for clipping that takes away part of the stroke so markers can have a hollow section, or a boundary around the edge
... I think what I specced might be difficult to use

<Cyril> https://svgwg.org/svg2-draft/painting.html#MarkerKnockout

heycam: I did it that way to avoid having to do some path geometry opertations
... I think a simpler way to do this would be with masking or compositing

cabanier: I think you'll have to special case it for compositing. The shape and the stroke will have to be treated as in a group

krit: Are you talking about the markers causing the knockout?

heycam: Subway station circle is a common use case

heycam draws an example on the whiteboard

<marker .... >

<path knockout />

<path ....>

heycam: I want to specify regions that knock out and regions that don't
... I want to knock out the center of the subway station circle

nikos: that's not how knock-out works

dmitry: the marker could have different masking capabilities, allowing you for example to apply a gradient as a mask

krit: I'd have two types of marker - a mask marker and a rendering marker

heycam: I'd like it to be part of the one if possible

Cameron writes another example

<marker marker-mask="url(#a)">

<path />

<g id="a">

heycam: Ideally we want to keep the mask group and the path together
... Does everyone think it's better to do this with masking than anything else?

Cyril: We have been trying to remove the use of ids, so following that it's better to have the mask as a child

heycam: How about a marker-mask element that is a child of the marker

shanestephens_: Having it apply to the first thing up the ancestor chain that is relevant makes sense

krit: So you'd always have to have a marker if you want to have a gap?

heycam: You could leave it blank
... I don't think we should use the name mask for the element, because it would require a special case of the way a mask applies to it's parent

heycam draws another example

<shanestephens_> marka mask: http://www.genuineafrica.com/images/Marka/African-Masks/African-Masks-Marka-Mask-32-F.jpg

<marker ...><markermask><circle ... r="20" /></markermask><circle ... r="10"/></marker><path d="..." marker-mid="url(#a")

krit: I think it would be a common use to mask without wanting to draw anything
... it would require a lot of mark-up to do that

heycam: I was originally thinking clipping, but using that wouldn't you have to do a lot of computation?

AlexD: clip-out is a common operation and is fairly simple

heycam: If there were two types of marker - drawing and masking, everytime you want to use that pair you have to include two references

krit: it would be good to set the order of the two types, first the drawing, then the clipping for example

heycam: The marker mask applies to the path though, so you want to apply all the masks then render the markers

dmitry: That's the way I'd expect it to work - the marker mask applies to the path and not to the previously drawn markers

Cyril: I think we need to consider what all the use cases are, we have only considered the subway station so far

heycam: I think this would allow an author to do the other things I have in the spec currently
... one issue I noted in the spec was that if the path is curving where you want to knock-out, you may want to distort the shape of the knock-out
... another question, is whether it would apply to the stroke and the fill, or just the stroke?

AlexD: I'd say both

cabanier: Just the stroke

heycam: I could see cases for both

Cyril: the marker position is affected by stroke-position right?

heycam: That's a good question

ed: if you change the drawing order with paint-order, do you still want to knock out parts that are drawn after the markers?

Cyril: The marker mask should mask anything to the left of the marker

heycam: I think that's the only way that makes sense
... I like this solution, I think it's far simpler for an author than what is in the spec currently

krit: what happens if the marker mask is after the marker graphic element?
... would the mask affect the marker?

heycam: no

Cyril: if two markers are close, the markers aren't affected by the masks are they?

heycam: No, only the stroke is affected

krit: I'm not sure about this, you would need to check every mask element to create the mask, it sounds complicated and error prone

heycam: I think you have to do all the masking first, you can do it per marker

krit: You can when you have the marker and the mask separately. Then you don't need to access the DOM twice

heycam: Is it because marker-mask is a child of the marker that it's difficult?

krit: Yes, because you have two different rendering contexts. One for each

cabanier: How do you combine the masks?

heycam: you just combine them all and draw as one

krit: If you had gradients in the mask?

heycam: You would have to composite them together

Cyril: If you had two overlapping markers and each had a left to right gradient. The middle would be lighter

heycam: You could specify blend modes and compositing operators on the marker-mask to define how they combine

krit: is marker-mask an alpha or a luminance mask? Can you specify one or the other?

heycam: good question, not sure
... I'm not sure it would be hard to implement. I could try writing something up and send it to the list?
... Can you do this masking in hardware?

krit: The biggest problem will be the position calculation of the markers

dmitry: if you replace masking with clipping does it make it easier?

heycam: I don't think so

shanestephens_: don't you need to traverse the paths anyway to place the markers?

krit: yes, so it doesn't make any difference whether you use clipping or masking

heycam: I'll write some examples and some text and we can decide later

<scribe> ACTION: heycam to write up examples and text for marker-mask [recorded in http://www.w3.org/2013/02/04-svg-minutes.html#action10]

<trackbot> Created ACTION-3423 - Write up examples and text for marker-mask [on Cameron McCormack - due 2013-02-11].

<cabanier> http://blogs.adobe.com/webplatform/2013/01/31/revised-canvas-paths/

Canvas path proposal

cabanier: The canvas spec proposes to allow for a path object to be constructed with SVG path syntax
... and you can combine, stroke, fill, with different winding rules
... it would be good to get the modified path data back out
... Google has implemented some of this

Cyril: is it really interoperable? I think in Inkscape, for example, they create an approximation of the path

cabanier: how is the quality of what is produced? If you have

s/cabanier: how is the quality of what is produced? If you have /cabanier: how is the quality of what is produced?

krit: it can be done by the GPU. But you can't get the path data back out

cabanier: If you draw using JavaScript and perform operations like a union, you can't get the path data from that

heycam: So this is in the spec already? Things like arc and path

krit: Some are

cabanier: The canvas spec has some problems with strokes interacting with itself

heycam: I'd like to solve the problem of multiple strokes on the one element without using vector effects. Like using lists on the element

Cyril: Vector effects elements seems to give a way of creating the paths that you can build up with Rik's proposal

heycam: With the proposal, can you inspect the path data?

cabanier: No, you can only draw it

Cyril: To me, there are a lot of similarities between this proposal and vector effects and they should be aligned

cabanier: The path just contains segments. It's quite dumb.
... shape contains the final result that you see on the screen. But you can still scale it and maintain quality
... The internal representation is completely different to what you input, so you cannot get the data back out

krit draws an example on the whiteboard that shows how 2 drawing operations result in a union of the two

cabanier: And you can specify winding rules that affect the geometry that is created
... In the final example you draw two circles, then you union them, then you stroke it

heycam: Can you put markers on it?

cabanier: The markers would be on the resultant paths created

krit: How would you perform the stroking when the path is required to stroke?

cabanier: The path is available internally in some form, it's just not exposed in the script

krit: If you can get an exact match (as output) for a straight line polygon, then you can specify what would result from curves

heycam: I'm happy for the paths not to be exposed to script

cabanier: Then you cannot use them in SVG
... as input

krit: What outcome do we want from this discussion?

cabanier: I just wanted to make you all aware of this. Dirk and I have been discussing it.
... It's more of a Canvas thing, but if people think it's reasonable we will implement it

heycam: One way you could bring it into SVG is to set the path data as the output of the JavaScript

ed: would that work with scaling ?

cabanier: You would have to recalculate the path

krit: it can be a specification issue if the browser is required to be pixel perfect
... you could specify that pixel accuracy isn't important

Cyril: Would your proposal work with any path, e.g. Catmull-Rom?

cabanier: yes

heycam: I like the proposal

Cyril: Would the paths created by this proposal be useful for CSS exclusions or anything like that?

cabanier: JavaScript is required though

Cyril: It would be nice if there was a declarative equivalent
... one of the advantages of having it as declarative in SVG would be that you could use it for CSS exclusions

heycam: Is it worth thinking about a non declarative way of getting the data into SVG?
... If you could just set the JavaScript object on your path element
... You don't want to allow the path data to be output. You want a way to refer to constructed path

Cyril: it's like what I was requesting before. A scalable representation without the full DOM.

cabanier: It could be a new way of drawing. Where you draw into an object.

heycam: When you do that, would it update the d attribute?

ed: as long as the path operators are the same

cabanier: There are some differences between the defaults in some cases (e.g. stroking)

heycam: If this proposal gets added to the Canvas spec, then we can make any corresponding SVG changes

krit: if you create a path object with a CTM in the Canvas context then the transformations will be applied to the internal path data

Cyril: if this is accepted, we will have a mechanism for a path element in SVG which has no d element but the path data is set from a shape object.
... do we have a mechanism to go from a declarative path to a shape?

cabanier: You can currently input an SVG path string but the stroking, etc are not applied

Cyril: So I can create the shape objects, then delete all the other objects and just be left with the shape object with no DOM

AlexD: Yes, you have JavaScript objects instead which are even bigger than the DOM representations

cabanier: What we could add is to have an optimise method that returns another shape constructed as the intersection of the other objects.
... currently, when you call the add method, it doesn't do anything to the internal path data. It only adds a command to the internal representation

heycam: Were you thinking that this path objects and it's improvements would remove the need for pathSegList?
... the path object currently doesn't have a way of inspecting individual segments?

cabanier: no

heycam: is that something you want to add?

cabanier: I don't think there's a reason we couldn't

Cyril: what if you serialised - you want to get the SVG

cabanier: You can't serialise a Shape as you can't get the data out

heycam: So we'll wait until this progresses further with the Canvas group?

cabanier: Yes,

<scribe> ACTION: Rik to look at how to attach a path or shape object to an SVG path element [recorded in http://www.w3.org/2013/02/04-svg-minutes.html#action11]

<trackbot> Created ACTION-3424 - Look at how to attach a path or shape object to an SVG path element [on Rik Cabanier - due 2013-02-11].

<Cyril> scribe: Cyril

SVG DOM path improvements

heycam: improving the SVGPathElement APIs

dirk: we resolved something in Zurich

<heycam> http://www.w3.org/2012/09/17-svg-minutes.html#item09

heycam: we have resolutions but no actions
... some of the resolutions are related to the previous discussion

<scribe> ACTION: Rik to edit the SVG 2 spec to add the possibility to set the d attribute using a Path object [recorded in http://www.w3.org/2013/02/04-svg-minutes.html#action12]

<trackbot> Created ACTION-3425 - Edit the SVG 2 spec to add the possibility to set the d attribute using a Path object [on Rik Cabanier - due 2013-02-11].

dirk: creating a new path automatically requires creating a move to because of underlying platform code in WebKit

heycam: the resolution from Zurich "add extendPath - which acts as addPath but trims off the initial moveto" is about that right?

dirk: yes
... Qt creates multiple moveTo
... sometimes, so you don't know if it's your moveTo or the one from the platform
... usually it doesn't matter, only if you read back

heycam: can you penalize only the Qt port ?

dirk: maybe, I don't know
... Core Graphics creates automatically a moveTo if the first is a lineTo
... everything is solvable, but how ? maybe we need to add a layer

heycam: when you're flattening you don't care about the new moveTo
... only when appending you want to preserve the original path

<scribe> ACTION: Rik to add the extendPath and addPath methods to the SVG 2 [recorded in http://www.w3.org/2013/02/04-svg-minutes.html#action13]

<trackbot> Created ACTION-3426 - Add the extendPath and addPath methods to the SVG 2 [on Rik Cabanier - due 2013-02-11].

heycam: the methods are on the Path object

dirk: d would not be the attribute but the path of the Path object
... how do you reflect that in the SVG DOM ?

heycam: some the segments in the Path may be different from the SVGPathSegList ones

<scribe> ACTION: Rik to add new procedural methods for catmull-rom [recorded in http://www.w3.org/2013/02/04-svg-minutes.html#action14]

<trackbot> Created ACTION-3427 - Add new procedural methods for catmull-rom [on Rik Cabanier - due 2013-02-11].

rik: I'd like someone to add the text for Catmull Rom for the XML part, and I'll refer to that

heycam: yes Doug will do that
... for the resolution "add canvas-like arc commands in svg path syntax", Tab is working on that

ACTION-3427: waiting on the action by Doug to do the edit in the SVG syntax

<trackbot> Notes added to ACTION-3427 Add new procedural methods for catmull-rom.

cyril: what about the stringifier

rik: I'll do that

<scribe> ACTION: Rik to specify the stringifier method for the Path object [recorded in http://www.w3.org/2013/02/04-svg-minutes.html#action15]

<trackbot> Created ACTION-3428 - Specify the stringifier method for the Path object [on Rik Cabanier - due 2013-02-11].

ACTION-3428: waiting for Tab on adding the new arcs command to the SVG path syntax

<trackbot> Notes added to ACTION-3428 Specify the stringifier method for the Path object.

heycam: the next thing is Brian's proposal for taking a list of numbers and making a path of that

brian: you've got an interface of Path for getting an array of floats, one array per subpath
... but we were stuck with the close command

rik: because it does not look the same if you explicitly close it or not

brian: dealing with the array of floats is faster
... than to traverse the segment list

<birtles> http://processingjs.nihongoresources.com/bezierinfo/

brian: if no one else cares, we can just drop it
... if we think it's worthwhile we need to find a way to handle the close command

<birtles> previous proposal: http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM#Making_Improvements

<birtles> section "birtles 2012-03-26: ..."

heycam: it seems pretty simple to write

brian: yes, because it's using normalizedPathSegList

heycam: are we extending PathSegList or the new path object ?
... maybe we should go on Path

rik: do you have an example ?

brian: no

dirk: we should find one solution to solve both problems: JSON and Array

heycam: the JSON was meant to be able to express all segment types not normalized

dirk: the Array may be JSONified afterwards

brian: I can spec it and we can drop it if there is not much interest

<scribe> ACTION: Brian to spec the setting/getting of an array of floats for path handling [recorded in http://www.w3.org/2013/02/04-svg-minutes.html#action16]

<trackbot> Created ACTION-3429 - Spec the setting/getting of an array of floats for path handling [on Brian Birtles - due 2013-02-11].

prioritization of remaining requirements

Cyril: next one is "Make it simpler to construct regular polygons and stars"

dirk: Tav has an action on it, but we haven't seen yet a proposal

heycam: let him and Doug work on it and see

cyril: next "Make arcs in paths easier"

dirk: that's Tab's action

heycam: I had also the turtle command for rotation
... to ease the creation of pie charts

dmitry: I don't know the final decision, but next Raphaël adds 3 commands for arcs (oval, arc, arc using 3 points)

<krit> http://raphaeljs.com/arc3.html

dmitry: I chose O and U

(dmitry drawing example on the board)

dmitry: the commands use the previous commands to get the missing parameters
... like the center, or start and end angles
... in most cases, the center will remain the same if you draw multiple arcs
... the basic idea is that the center is derived from the previous command, it is not specified in the current command
... I decided to use degrees, not radians

dirk: if the center does not change with an arc command but changes with another command, you have 2 store 2 last points
... Canvas arcTo commands are more complex that Dmitry's

dmitry: there is also the arc3 with 3 points

dirk: it is a nice demo but I don't know how useful it is

alex: it is part of HPGL since 40 years

rik: most of the time you want to use the arc segment to be hooked to the previous path

dmitry: it has been heavily requested by the community

heycam: we have one method in SVG, 4 in Canvas, dmitry's ones, that makes 8 different arc commands

cyril: does this go in SVG 2 or in SVG.next ?

rik: Tab should take care of that

RESOLUTION: "Make arcs in paths easier" may go in SVG.next unless Tab's actions are done in time for SVG 2

cyril: next "Allow objects to be positioned along a path"

heycam: this is the thing Doug refers to ShapePath

alex: just define each shape as each glyph in a font and use textPath

dirk: SVG fonts are not supported in all browsers

heycam: markers could be used too

alex: it is also using several animateMotion elements with offsets and not moving

RESOLUTION: "Allow objects to be positioned along a path" is already solved at least using 2 different ways so no action required

cyril: next "Require automatic text wrapping in arbitrary shapes compatible with CSS"

alex; isn't it implemented in Inkscape and CSS refused

shane: that's why it says compatible with CSS

RESOLUTION: Automatic text wrapping will go in SVG.next unless Tav comes with text

cyril: next "Support glyphs being aligned to different baselines, perhaps by using existing or improved CSS properties"

alex: don't we have that ?

heycam: using dominant baseline and so on
... the part about baseline has to be rewritten to use CSS

<scribe> ACTION: heycam to insure that the text chapter talks about baseline in terms of CSS features [recorded in http://www.w3.org/2013/02/04-svg-minutes.html#action17]

<trackbot> Created ACTION-3430 - Insure that the text chapter talks about baseline in terms of CSS features [on Cameron McCormack - due 2013-02-11].

cyril: next "Clarify the stretch method for textpath"

http://tavmjong.free.fr/SVG/TEXT_PATH/TextPath.html

heycam: I thought this was more about filling in some wholes about textPath

alex: Tav's stretch is already spec
... Corel implemented

erick: this is not fully specified

alex: the last examples from Tav's page are not specified
... some fonts have copyright issues that don't let you have access to the point data so manipulations of glyphs is not easy

dirk: Canvas is supposed to expose the glyph to JavaScript

rik: but it's not implemented

alex: maybe because of the copyright issue, to avoid ripping fonts

dirk: users should not have access to the glyph data

alex: there are flags in the font package that say do not modify me

heycam: do we require the stretch method to have particular behavior

dirk: no, it is already specified in 1.1

heycam: do we add constraints on how the strectch is made

dirk: it could be a separate module

RESOLUTION: defer "Clarify the stretch method for textpath" to SVG.next

Cyril: next "Have a way to specify flip-invariant text"

alex: I would use SVG Tiny ref transform to stop the flipping

cyril: we have accepted transform="ref" (point 90)

alex: I think we should add it to the use case list for constrained transforms

RESOLUTION: consider "Have a way to specify flip-invariant text" as part of the constrained transforms item

cyril: next "Deprecate the use of xml:space to affect layout and will use the CSS white-space property"

heycam: partially done, I'll do the rest soon
... there was a discussion of mapping xml:space with whitespace using user style sheet
... we do that under the hood in Firefox
... but that creates problems when inheriting the whitespace property of between SVG and HTML

RESOLUTION: "Deprecate the use of xml:space to affect layout and will use the CSS white-space property" is still part of SVG 2

cyril: next "Allow transforms on tspan"

dirk: it is already the case
... due to the rewrite of the interfaces

heycam: it probably needs an example

RESOLUTION: "Allow transforms on tspan" is covered in SVG 2

cyril: next "Support Coons patches"

heycam: Mesh patches are already added by Tav

cyril: I still have an action to look at freeform gouraud meshes
... but couldn't for this meeting

RESOLUTION: "Support Coons patches" is already in SVG 2, we keep it

cyril: "Have a video element in SVG namespace with the same characteristics as the HTML 5 video element"

alex: we have a discussion on this tomorrow
... I've invited Silvia Pfeiffer to talk about that

cyril: next: "Have stronger requirements for when to display tooltips"

dirk: that was a discussion we had already
... Doug needs to talk Rich

RESOLUTION: "Have stronger requirements for when to display tooltips" still goes in SVG 2, pending on Doug and Rich discussion

cyril: next "Support pointer events sensitive to alpha, subject to security constraints"

alex: the use case is for Farmville
... having a PNG with alpha and do hit testing on the images

dirk: maybe the should use canvas and hit regions

RESOLUTION: defer "Support pointer events sensitive to alpha, subject to security constraints" to SVG.next

cyril: next "Support HTML document wide events (including hashchange) apply to SVG documents when they make sense"

heycam: we should still do that, I will do that

erik: that's already implemented in browsers, at least some part of it

heycam: I wouldn't be surprised if the document.addEventListener('hashchange' ... work

dirk: maybe we move these attributes

heycam: they may have moved already to Element

dirk: we can push other specifications to move some to Document or Element

heycam: we need to say SVGElement implement GlobalEventHandlers

<heycam> http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#htmlelement

heycam: or we need to ask to move them to Element instead of HTMLElement
... I'll do that as part of the action

RESOLUTION: "Support HTML document wide events" still in scope of SVG 2

cyril: next "(may) Support drag&drop functionality"

erik: I have an action on that but it depends on the eventhandler thing
... we need only to add the attributes to SVG, the rest is specified in HTML
... I could start working on it

heycam: you could do that and leave out the event stuff

RESOLUTION: "(may) Support drag&drop functionality" is still in scope for SVG 2, it is a small change

cyril: next "Make it easier to detect if an mouse event is on the stroke or fill of an element"

heycam: done

cyril: next "Allow async/defer on the script element"

heycam: yes we should keep it
... I remember Boris being worried about a document.write related thing

RESOLUTION: "Allow async/defer on the script element" is still in scope for SVG 2.

cyril: "Support for non-negative speed on time containers (if we decide to include time containers)"

brian: we do negative speed in Web animations, only on the root

RESOLUTION: "Support for non-negative speed on time containers" is part of Web animations

cyril: "Support path-based animations of pairs of attributes"

brian: I'm not sure about that

heycam: it came from applying x,y attributes from animateMotion and apply it to two elements

brian: the model of Web Animations should support that
... given solid use cases, we can add it to the next version of Web Animations

RESOLUTION: "Support path-based animations of pairs of attributes" will be added to future Web Animations, pending solid use cases

Cyril: next "Define all explicitly undefined parts of the SVG 1.1 spec (wrt to to-animations)"

brian: that will be covered in SVG integration to Web Animations
... to animations in SVG is weird

RESOLUTION: "Define all explicitly undefined parts of the SVG 1.1 spec (wrt to to-animations)" will be covered in SVG integration with Web Animations

cyril: "Define all explicitly undefined parts of the SVG 1.1 spec (wrt to to-animations)"
... "Allow CSS-transitions-like animations"

brian: it's about snapshoting

RESOLUTION: "Allow CSS-transitions-like animations" is deferred to a further version of Web Animations, pending more details

cyril: "Allow linear interpolation for properties which were previously discrete"

brian: it's about text anchor
... Chris should be doing it

ACTION-3209

<trackbot> ACTION-3209 -- Chris Lilley to write up a proposal for allowing linear interpolation of properties that were previously discrete but could be reasonably interpolated linearly -- due 2012-01-20 -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/3209

shane: in CSS this kind of thing doesn't really make senss
... Tab proposed to snapshot the page in the first and final state and to interpolate everything
... there is a good chance that CSS will go in this direction

RESOLUTION: "Allow linear interpolation for properties which were previously discrete" is deferred to SVG.next, unless Chris comes up with a proposal

cyril: next "Support animation using a transform-list"

brian: that is in CSS transforms

dirk: this is linked to the decomposition of transforms

brian: SVG integration with Web Animation will refer to this decomposition

RESOLUTION: "Support animation using a transform-list" is in scope of Web Animations

cyril: next "Support motion animation of a specified speed"

brian: defered in web animations
... we think we can address that with the model, but not in the first version

RESOLUTION: "Support motion animation of a specified speed" is deferred to a future version of Web Animations

<trackbot> Date: 04 February 2013

<heycam> Meeting: SVG WG F2F Sydney 2013 Day 2

<ed> chair: erik

<heycam> ScribeNick: heycam

Relation between enable-background and isolation property

krit: we have the enable-background property and the isolation property

… two properties with different name but with the same context, they're supposed to do the same thing

cabanier: except that isolation has different default values: auto | isolate, enable-background default value is always accumulate

<cabanier> spec for isolation: https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#isolation

<krit> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#EnableBackgroundProperty

krit: the idea is that you can get the background of an element that you want to filter

… and have filter operations based on the background

… this is useful in blending and compositing

… with feBlend and feComposite

… the problem is that the relation between enable-background in the past is the same as isolation; that's why we wanted a shorthand

… enable-background preserves the background up to the previous enable-background:new regardless of what graphics are in between

… this is the default behaviour

… similar to z-index, making a new stacking context

… isolation in the past did the same thing but with different keywords

… the default behaviour now has changed, though

cabanier: but you can say enable-background works on filters but isolation works on graphics

krit: you could but we shouldn't
... do we still want to preserve both properties with different behaviours?
... does it make sense to have two different stackings, one for filters and one for compositing?

nikos: they are for different purposes

… the reason behind enable-background was an optimisation, if you don't have "new" anywhere then background image isn't available

… by setting it to new, you're making a certain region of the document available in the background

krit: that's just like in compositing

nikos: but they're for different reasons -- for enable-background it's an optimisation, for compositing it's for the effect you want

krit: from the implementation pov, there's some cost to implement both

… sometimes it's even not possible

… if you have overlapping background regions from both properties

cabanier: has anyone implemented enable-background for html?

krit: no

cabanier: we could say that isolation:auto defaults to providing background in svg elements and not in html elements

nikos: I think they should be kept separate, but when you apply a filter to a group the group is isolated

alex: you have to do it that way anyway

nikos: that's what illustrator does

cabanier: sometimes...

heycam: what is the proposed change?

cabanier: we can make enable-background "auto" ...

krit: but it would still mean that you'd have two different stacks

cabanier: we can just make enable-background and isolation mean the same thing

krit: the main thing is that the situation has changed last year… the behaviour of Compositing has changed

nikos: they can't influence each other; if you apply a filter to a group makes it isolated

krit: if you have enable-background:accumulate isolation:isolate what happens?

nikos: [draws]

krit: we should have shared text between Filters and Compositing saying you isolate up until the ...

Cyril: you can say isolate has two purposes; one is for compositing and one is that it affects filters as if it were enable-background:new
... would need to define what happens if you put isolation:isolate;enable-background:accumulate on an element

nikos: if you have enable-background:accumulate;isolation:isolate that's not going to make a difference

Cyril: cabanier says isolation takes precedence
... what "auto" in isolation? is that different from "isolate"?

cabanier: it's mostly not isolated, unless you have opacity or something that creates a stacking context

ed: where should this go?

krit: I'd like to share the wording, and reference Compositing from Filters

cabanier: if you really wanted enable-background to only to apply to filters and not influence compositing, you couldn't

krit: SVG needs to say what stacking is

ed: jwatt wrote up a z-index proposal, what stacking contexts means -- that might be enough

krit: then define how Filters and Compositing/Blending interact with stacking contexts in SVG

Cyril: will there be any difference between SVG and HTML?

krit: no

cabanier: you might want to blend something with opacity with the background in SVG… which isn't possible in HTML/CSS

<ed> http://lists.w3.org/Archives/Public/www-svg/2009Oct/0042.html (jwatt's z-index proposal)

krit: why doesn't isolation have a new value to mean never isolated?

Cyril: when you use CSS Transforms on SVG elements it makes a stacking context, but if you use the attribute it doesn't?

heycam: that seems bad

krit: that's not how it's implemented
... if you have a transform you should isolate this?

alex: this doesn't make sense in HTML

krit: I think transforms shouldn't affect blending/compositing in SVG
... we first need to know if Compositing and background are affected by stacking contexts

ed: we could use a new term and maybe make it equivalent to stacking contexts later

nikos: "isolated group"

cabanier: I think doing that for CSS will be a nightmare

krit: transforms being affected by stacking contexts is stupid

cabanier: maybe CSS Transforms should be updated?

<scribe> ACTION: krit to ask CSS/FX how blending is supposed to work with transforms [recorded in http://www.w3.org/2013/02/04-svg-minutes.html#action18]

<trackbot> Error finding 'krit'. You can review and register nicknames at <http://www.w3.org/Graphics/SVG/WG/track/users>.

<scribe> ACTION: Dirk to ask CSS/FX how blending is supposed to work with transforms, opacity, all properties that create stacking contexts [recorded in http://www.w3.org/2013/02/04-svg-minutes.html#action19]

<trackbot> Created ACTION-3431 - Ask CSS/FX how blending is supposed to work with transforms, opacity, all properties that create stacking contexts [on Dirk Schulze - due 2013-02-11].

iframe proposal

stakagi: we have a document

<stakagi> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IFrame_Like_Syntax

birtles: let me summarise

… in the Abstract there are three main parts

… one is the iframe element; takagi-san has written out spec text to allow iframe in SVG

… it's similar to HTML's iframe element

… one addition is the second point, the levels-of-detail, and it uses a media query to determine when to show the iframe's contents

… it's an attribute on the iframe itself

… the third part is the global coordinate system, and there's some discussion about what that is useful for in the issues section

Cyril: except for the coordinate system, it looks similar to the <picture> element or srcset

… the responsive images, where they want to load one resource or another based on media queries

birtles: wrt the media attribute?

Cyril: what's the difference between <img> and <iframe> in this case?

heycam: it's meant to be just like an HTML <iframe> here

krit: I thought some WebKit engineers were unhappy with <iframe>

… and maybe they would not like it in SVG

birtles: I've heard the opposite feedback, that <iframe> is the way forward, and people shouldn't use <object> and <embed>

… for example we have seamless and sandbox on iframe now

krit: for security concerns

birtles: yes to make it better

… so this proposal would allow those attributes on <iframe> in SVG too

nikos: this doesn't talk about the difference between seamless or not

birtles: it's not in this document, but we have discussed it

… I'm not sure how much we need to say

… the behaviour would be the same as in HTML, in how you inherit styles

… that's all common

… one area of difference is do you have a border

… that does need to be defined

Cyril: what's the difference between <iframe> and <img>?

ed: iframe has interactive, img is static

birtles: there used to be a difference where <image> in SVG was static as in not animated, but that's changed to allow animation now

alex: so iframe is like the old <animation> element

ed: this is basically how we implemented Tiny's <animation> element -- as an <iframe>
... the first thing then is do we want to have an iframe element and in SVG 2?

heycam: we should write down somewhere how foreignObject requires HTML to be rendered etc.

krit: so this proposal has an addition?

birtles: yes that's the next part of it

krit: does it make sense to allow that on original <iframe>?

birtles: first question is whether we should allow <iframe> directly in SVG

… second is whether to have media="" just on SVG's <iframe> or on HTML's too

Cyril: I think the <animation> element had good points, but maybe too many in the same element, e.g. control of timeline

… and the linking to SVG content

… maybe it's a good idea to split these

birtles: this isn't about controlling the timeline

Cyril: that's why I'm saying it's a good idea to split these two
... we should have a common solution across responsive images

krit: should we use <iframe> in SVG directly instead of inventing it again?

birtles: yes it would be kind of like a shortcut in SVG without <foreignObject>

… it would be in the SVG namespace, just for convencience

… it's not reinventing iframe, but importing it and smoothing over the gaps

Cyril: now in respimg they are talking about srcset in <img> or a new <picture> element

… which are both only for static things

… if you have a map that's interactive you couldn't use <picture>

<stakagi> First of all for with responsive images compatibility, I introduced media attribute.

heycam: maybe srcset or whatever could apply to <iframe>

birtles: srcset is more about selecting from alternatives, here <iframe media> is about when to turn the element on or off

<stakagi> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IFrame_Like_Syntax#5.11.1_Additional_Media_features

heycam: could you use scoped style sheets instead media=""?

birtles: media queries will fetch all of the matched things, but in this case we don't want to load everything at once

Cyril: same thing for respimg

<stakagi> Especially, i think 'close-viewport' is unique feature

birtles: within that media="" attribute, there's a proposal for some additional media queries

… there are two

… zoom and close-viewport

… they're additional tests to define when the resources are loaded; one is the zoom factor, and the other is how close the tile is to the viewport

Cyril: close as in nearby

birtles: you give a radius around the tile, once the viewport overlaps with this region load this resource

nikos: why would you let the author set that?

birtles: one view is to let the UA choose that to optimise

alex: if you pan the map you'll want to prefetch the tiles you're about to see

birtles: even if we were to use srcset, these additional media queries could still be useful in that context

Cyril: this is touching a lot of areas, CSS, HTML...

… I am not sure how we can proceed in the SVG WG, coordinate with the other groups?

birtles: there are different routes

… pointer-events was something that was in SVG initially and then later was adopted more widely

… we could say this media="" stuff only applies in SVG

… and I think it has more relevance in SVG

Cyril: we shouldn't give the impression that we're modifying <iframe> unilaterally

birtles: the thing to decide today is do we want to pursue a native <iframe> in SVG, and what direction would we like to do with media=""

krit: this is somehow in conflict with the discussion of how to allow all HTML elements directly in SVG

<ed> -- 15 min break --

<krit> scribeNick: krit

HTML in SVG

<heycam> ScribeNick: heycam

krit: the problem is that HTML uses the CSS box model

… all HTML elements have this CSS layout

… one problem is that SVG has coordinate based drawing, CSS/HTML has layout based

… I suggested on whatwg to use something other than <foreignObject>

… we could create a shortcut for this, it just takes a width/height and position and everything inside is HTML

… inside that you have the CSS box model

… that would be one way to do it

Cyril: I taught SVG this winter to a group of students, they were mixing SVG/HTML with foreignObject, body, etc.

… they knew how to do it easily

krit: it's a lot of code that you waste

… you have to specify <foreignObject>, html namespace, body

heycam: I thought we wanted to try to avoid having a wrapper element

Cyril: are you switching parser in the middle? if you have XML on the outside and you get to this new element, would you switch to HTML parsing?

heycam: no

… that couldn't work

cabanier: in HTML don't you switch to SVG parsing when you get <svg>?

heycam: it's switching mode within the HTML parser, not switching parser

Cyril: when you have a <foreignObject> with HTML inside, does it have to be XML-compliant HTML?

heycam: yes

Cyril: can you have a <video> self closed tag?

heycam: in XML? yes

cabanier: if you have an HTML file with inline SVG, and inside that you have <foreignObject> how is that parsed?

heycam: that's still HTML

Cyril: <foreignObject> needs an HTML namespace?

heycam: on the children of <foreignObject>, say the <body>

Cyril: you just want to replace <foreignObject> with <html>?

krit: in addition, not replace

heycam: I don't think you can make HTML elements inside <svg:html> automatically get parsed into the HTML namespace if we're being parsed as XML

ed: that wouldn't allow us to have <iframe> directly as a child of other SVG elements

… <iframe> is a bit special in that it defines a rectangular region, just like <foreignObject>

krit: you cannot just put an HTML element in SVG context

heycam: we could make it so that the namespace URI, whether it is SVG or HTML, doesn't matter

… thus you could have <g><div></div></g>, and <div> would be in the SVG namespace, but that wouldn't matter -- it would behave the same as an HTML namespaced <div>

heycam: Tab also suggested at one point having no namespace, so <svg> as the root, no xmlns

… and then all the SVG- and HTML-named elements could be in no namespace

… but you would still get SVGCircleElement, HTMLDivElement objects created for them

heycam: one problem with <iframe> as a direct child of <g> is how to specify the position of the iframe

… you could use style="top: …; left: …" or style="transform: translate(…)"

… SVG has a bunch of global attributes like transform="", presentation attributes, etc.

… should these be allowed on the <iframe>-as-a-child-of-<g>?

… I feel like we should have <iframe> functionality in SVG

… without having to have intervening HTML

birtles: <iframe> has some features which would be useful in SVG as well, like seamless for applying styles across nested browser contexts

… and sandbox as well

heycam: I am a bit worried about these extra attributes on SVG's <iframe>

… if later we want to unify it and HTML's

… if we allow x="" and y="" and transform="" and display="" on our <iframe>, and later we have a plan to allow all HTML elements as direct children of SVG elements, it would be bad if they stopped working if the element was in the HTML namespace

… I'd like much the same behaviour across both namespaces

… (x and y might be ok to have not work in HTML namespace, since you want to rely on CSS for layout)

Cyril: what about for HTML <video>?

birtles: that raises the same issues
... with x and y, I wonder if you could define those to only make sense/apply in SVG contexdt

… and reuse that for both iframe and video

… x and y would mean "the SVG offset", and by definition wouldn't work in HTML

… the next step, when we try to expand integration further, we could decide if we wanted those on <div> and <p>, but that's a separate question

[some talk about the difference between width/height properties and attributes on canvas/video/img]

ed: to me it seems all of these HTML elements that have width/height, it's a separate problem from all the other HTML elements like p/div

… I think those that have width/height already would be easier to take in as they are, more or less

… the qn is whether to do that first, or consider the whole set of elements

[discussion of which spec iframe would go in to, SVG 2 or another; takagi-san prefers SVG 2, but whatever is quicker]

ed: I think it makes sense to do all of video, canvas, iframe at once

… I wouldn't mind it being in SVG 2

heycam: what to do with all the presentation/global attributes that would otherwise be on SVG elements?

ed: just allow x/y to begin with?

heycam: I think that is safest

RESOLUTION: SVG 2 will have iframe, canvas, video in the SVG namespace and with the same behaviour as HTML's, but allowing global SVG attributes on them
... iframe, canvas, video will also have x="" and y="" attributes in SVG, which eventually will be presentation attributes for the new 'x' and 'y' properties

<scribe> ACTION: stakagi to edit SVG 2 to add the iframe, canvas, video elements [recorded in http://www.w3.org/2013/02/04-svg-minutes.html#action20]

<trackbot> Created ACTION-3432 - Edit SVG 2 to add the iframe, canvas, video elements [on Satoru Takagi - due 2013-02-12].

birtles: the next thing is the media="" attribute

heycam: I think the specs should say whether media="" means fetch up front or only once it starts matching

… I'd like it not to be different from media="" on style, link, but I can see that preventing resource fetching is important for tiles/maps

birtles: in the proposal media="" acts like a conditional processing attribute

… so it should prevent processing of elements altogether

… maybe it needs a different name

… the reason for choosing media="" was to match the <picture> element

<ed> -- lunchbreak --

<krit> ScribeNick: krit

HTML5 video element in SVG

<Cyril> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2Multimedia

Cyril: Questions related to this topic.
... We decided to use HTML5 video element instead of tiny video. I implemented it and have quesions
... what about bollean attributes without values?
... What about self closing tags

krit: they shoulld be closeable

heycam: yes, the parser should ignore that and not closing tags should be able to have closing tags

Cyril: ok
... checked with tiny waht we miss
... tiny has a timeline
... they are in webanimations, but will they be in media elements?

birtles: we discuss it next week and have ideas

silvia: i like the idea of timelines

Cyril: timeline is on doc for tiny
... pause on element you don't care
... how do we have this feature in SVG?

birtles: talk about it that next week
... we didn't get put the mechnaics now

Cyril: you need to be careful of timelines between groups

shanestephens_: we should take care of it
... if we don't, the media controler should provide it
... but we want to make it work

Cyril: do you wat to control the doc timeline (start timeline on load)

birtles: yes, we define what 0 line is on a documen

t

silvia: you could have the media group under the timeline
... every media element has a videocontroler
... media controlers are objects that can be shared?

s/shared\?/shared(\?)/

Cyril: animation element whcih has 2 features
... link to animation, control the timeline, how in webanimations

?

birtles: webanimations has timing groups
... <par> and <seq>

Cyril: animations can poiint to a external document

shanestephens_: I would modify media controler to have a timeline. Seems better

Cyril: image with ref to image… no timeline. video would have with resource restrictions
... video should point to svg content to control timeline on this svg content
... image does not have any control
... no MediaElements interface
... I would not expect a video to run script
... cartoons are one example
... come back to streaming later

silvia: should be in HTML first

birtles: right

Cyril: yes, commen problem: spec features between html and svg
... how can i run and stop video declaritly
... in html you need scripts and events

birtles: ah, needs to be expressed in webanimations

Cyril: svg document and html document differ and both do not have timeline

birtles: all documents have a timelien

shanestephens_: embedding does not worry me
... when you use css svg then this will introduce a timline given by WebAnimation
... html will have a timeline

birtles: so you want 10s after document load?

Cyril: yes

birtles: you can do that with svg animation already
... but you can not do with nesting animation yet
... we need to think about a declaritive way
... might be different to pass it through WG.

shanestephens_: don't think so

Cyril: css animtions trigger when style attached. This was not possible to synchronize
... how to fixx that

birtles: intentionally it will be fixed magically
... e.g. time groups are one way
... no absolute time in CSS yet, but could be added
... helps synchronizing
... more work on CSS side needed

shanestephens_: there is more that we need to discuss with the CSS WG
... we should work on appro. to sync CSS to the CSS WG

Cyril: in tiny we had transformable attribute
... transforms like scale could be defined that it just had an affect on the position

krit: so CTM gets transformed but just affects the position?

Cyril: basically
... do same restrictions apply? do we still need that?
... if so, it should be in CSS Trnasforms?

AlexD: maybe

shanestephens_: we should come up with a unified model for transforms

heycam: like trnasform-behavior: normal and position?

Cyril: yes, where you transform CTM, or just a point
... where is transform on text?
... not in CSS transforms,

?

AlexD: no, we do that

Cyril: synchMaster and tolerance
... nother point in SVG tiny
... what if one point is lacking
... then you can define if you do not care if audio and video are in synch or not. It was possible to allow a tolerance

shanestephens_: mediaControler does it, but no master

birtles: webanimation it is sometimes hard to do simple things

shanestephens_: spec of tiny is very hard to understand and read

Cyril: but the model is simple

shanestephens_: is the spec not easy enought ridden or the spec not good enough?

AlexD: former

<birtles> (we decided in web animations not to address sync tolerance initially, but just to have strict synchronisation)

birtles: we won't allow tolerance in the first version

Cyril: RTP is not used much, so it might not a valid use case, but people use multiplex streams, they won't like
... but hybrid cases, different streams from different media, sounds interesting

shanestephens_: yes, there are things that ususally separate video and audio stream for example

silvia: in html it is regarded as quality of browser
... html allows implementation to decide about the tolerance level
... if i am web dev, and have 4 medias. Then I want them come in enought speed, so that they can displayed together
... let browser decide how to get quality for streamed media

Cyril: yeah, but sometimes it depends on one master
... but ok for now
... what baout visibility? start from 10s of video, should it display one fray for this 10s?

heycam: Can you do that?

silvia: it always does that
... either give it a poster, or it will give the first frame. not described in html, but the way it works

Cyril: basic interface of media seems to be the same
... did not lost anything to tiny

birtles: media attribute on iframe

media attribute on iframe

silvia: is this about media queries?

all: yes

Cyril: iframe is one way to get HTML things into SVG

(see minutes of morning)

birtles: usecase: map and you want control when resources are loaded and displayed
... media attribute defines (with media queries), when this will happen
... media for attribute with two different behvaiors (we meean dont load, don't show) but we want don't show but load if you like
... maybe we rename it to sth. else

<stakagi> The srcset attribute : An HTML extension for adaptive images : http://drafts.htmlwg.org/srcset/w3c-srcset/

<stakagi> The picture element : An HTML extension for adaptive images : http://picture.responsiveimages.org/

silvia: there is also reload audio/video and so on
... this is related
... means load if you can

birtles: media on iframe don't show this resorese and preload can allow to allow or disallow pre loading

heycam: would it be fine to turn of poss of iframe to laod and show of iframe?
... or think of media attribute as controlling multiple things (?)

Cyril: would our iframe prop. interesting as usecase for <picture> and srccset discussion?

silvia: no, differetn
... media queries specify range of conditions
... in this size use this, this for another screen size?
... what is it on iframe?
... how do you define the range?
... would make a lot more senese
... especially for going to the picture element
... what is the use case?

birtles: SVG conditional prpoposing attr.
... it is choosing between possibilieties like <switch>
... common case you wouldn't

silvia: don't think that is going to work
... rather embed frame with iframes in there and only one is chosen according criterias

birtles: how is that working on tiling in the mapping use case?
... you have a lot offrames with same query

silvia: is it a use case to turn of tiles?

Cyril: maybe on details
... as more you zoom in, as more details

birtles: you zoom in and get new tiles for this level?
... don't you think this is accepted?

heycam: if you could use <switch> in HTML....

silvia: you getting SMIL back to live once per peace
... do you have an example

birtles: yes

<birtles> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IFrame_Like_Syntax#7.10_Establishing_a_new_viewport

Cyril: in this case you just want to conrol loading

birtles: yeah, ok

Cyril: smae problem as on resp images
... use cases might be different enough. I your case all tiles will have the same queries on a given layer

<Cyril> s/I your/In your/

birtles: waht about extensions to media queries regarding to zooming

ed: maybe a topic of FX TF or CSS WG

<scribe> ACTION: birtles to discuss iframes with media queries with CSS WG [recorded in http://www.w3.org/2013/02/04-svg-minutes.html#action21]

<trackbot> Created ACTION-3433 - Discuss iframes with media queries with CSS WG [on Brian Birtles - due 2013-02-12].

streaming of SVG

<Cyril> http://www.w3.org/Graphics/SVG/WG/wiki/SVGStreaming

Cyril: In Seattle F2F I made wiki page
... had an action a concrete guideline
... put it on my web site for now

<Cyril> http://perso.telecom-paristech.fr/~concolat/SVG/streaming/

Cyril: some times you want to stream SVG content
... discussed few use cases
... defined terms
... what is SVG stream, what is a part of it, how do you access a part of this stream
... tries to brdidege a proposal mp4 together with TTML
... defines a concept how to map sources
... use cases are cartoons
... you jump in at any time 24/7
... would be good to make broadcasting of cartoons
... popcorn js does similar things
... things are not meant to be streamed
... live stream not easy
... use cases are valid in web content
... in multi media player as well
... I started what we have now (progressive rendeirng without control yet).
... communication between client and server missing
... do not forward referecnes
... element of the future not there, so no content, you are stock
... on progressive rendering you want content be synchronized in painting
... you can add scripting as well
... for simple things the guideline help you
... but often you want more
... correct displaying on jumping
... used access units, generiv term
... SVG document is cut into parts and defines and start access units
... on concatenating, the peaces get a valid document
... a cartoon would cut into frames
... you seek into this stream
... you need to look at the points when you jump
... I defined svg stream header.
... helps on seeking
... it helps to simulate playing from the beginning on cut in peace stream
... to hget a valid state in a stream, you need to care of haveing a valid DOM, scoped stylesheets and maybe JS in a correct state on every position

heycam: is this an authoring requirement?

Cyril: author defines a state that you would like to have

heycam: so browser must allow you that

Cyril: yes
... seeking in an SVG stream
... in the future where you don't have the data
... you need to know what you want to fetch
... hte SVG stream header indicates this

heycam: do you have an header

Cyril: different ways to do that
... in a container, separate file
... like WebVTT
... WebVTT give you the time offsets
... I descirbe how you might use this in HTML5

silvia: when you asked to put SVG as source files for Video, is that waht you asked for.

Cyril: yeah

silvia: this gives you a bunch of restrictions
... it needs a timeline

Cyril: there is already a timeline

silvia: 2s into the file must be the same for every person

Cyril: I think this is the case

birtles: yes, you can synch this

Cyril: if you start storing
... container will give you duration
... author needs to give duration and can be used to loop
... mp4 file does not need to be video, can cntain everything

silvia: <video> can already point to mp4, even with these things embeded into mp4

Cyril: right
... waht is SVG in HTML track?
... discussed this in the proposal
... I'd like to publish and get feedback

birtles: how much is required of UA, servers and authors

?

Cyril: as UA, you feed stream to preprocessor
... don't think there is much to change in browser to support this
... for servers there is nothing to change
... they do mp4 already
... mime type is different
... to clarify that a container has a SVG inside
... but is not SVG

silvia: webM is not a generic container
... just for audio and video maybe WebVTT

Cyril: is it a valid use case for WebM

?

silvia: not at the moment
... webm doesn't support it and UA's won't support it anyway, since they would need to parse it. don't find a browser that can handle this

Cyril: authors need define Cartoon and then access points + packaging

silvia: has consequences to put markup data into container that is used to work on pixel data
... things like Canvas assume to get pixel data on video

birtles: what baout tools?

Cyril: we have an svg player and a tool to create container files

birtles: isn't there a lot of potential to get it wrong?

Cyril: Haven't make the tool for reconstructuring
... where can I put it?

silvia: feels like it does tooo much
... sounds more like 10 specs

Cyril: put it into different sections

silvia: sounds that some parts would be specified by MPEG

Cyril: yeah, maybe we do it at MPEG or W3C

RESOLUTION: Cyril will upload this document for further discussion in this group

<ed> -- 15min break --

<birtles> scribenick: birtles

Glyph selection and positioning; associating text with graphics

heycam: I want to see if anyone has a proposal for this, or how important it is
... regarding the glyph positioning in SVG
... a way of selecting and positioning *glyphs* as opposed to *characters*

cabanier: isn't this already possible?

krit: no that's just unicode, not glyph id

ed: the only way I know of is to use altGlyph with an SVG font

heycam: altGlyph as a name attribute and you can select glyph by name

ed: I think it's by id
... although there might be a name as well

<ed> http://www.w3.org/TR/SVG11/text.html#AltGlyphElement

krit: nowadays a lot of people icon fonts
... is that the use case?

heycam: now, it's more for things like converting PDF to SVG
... you want to position glyphs exactly
... so you want predictable glyph selection

AlexD: the solution in XPS is to have both a character string plus a list of glyph IDs
... and the package includes the font
... so you're guaranteed to have the glyphs

heycam: I also want to be able to have some graphics with a text string associated with it

cabanier: are you trying to emulate PDF CID fonts

[explanation of what that means... it just has single offset, works in one direction, so you don't have to specify x,y every time]

scribe: it also includes an n-to-m mapping so you can say this set of glyphs represents this set of characters

heycam: altGlyph also has this

[some discussion about how altGlyph's addressing works]

scribe: so are people interested in solving this in the SVG2 timeframe?

cabanier: how does this work in pdf.js?

heycam: it renders to canvas and creates hidden spans over the text so you can highlight it

cabanier: so doing it with canvas sounds problematic. it sounds like we need to solve this
... identity encoded fonts are so easy

heycam: one thing about altGlyph is that you can use it in the middle of other text too
... e.g. <text>abc<altGlyph glyphRef="100">de</altGlyph></text>
... "abc" will use usual layout and font-fallback
... but "de" might, in this case, be represented by a single glyph 100
... but what if the text direction differs?
... what does it mean to have absolute positions in this case since the whole thing can be shuffled around?

cabanier: so you're mixing absolute positioning with default positioning
... it would be easier if you switch modes when you have glyph IDs
... so maybe you need <idText> or <cidText>

heycam: <glyphs>?

cabanier: something like that

heycam: do you still like the idea of having glyph IDs and character data
... would a list be better
... not one altGlyph per glyph

AlexD: yeah, a comma-separated list would be better

cabanier: you might want to define the mapping up-front

heycam: is that how CID fonts work?

cabanier: not CID, but PDF

heycam: so you define a table up-front?

cabanier: yes

heycam and ed: but for SVG we want to have the unicode text there as well as a fallback

scribe: not just a series of glyph IDs and a table

heycam: so CID is either horizontal or vertical and then just offsets?

cabanier: yes, you start with the CTM and then just offsets
... and it's always LTR or top-to-bottom
... and the default just uses the default width

heycam: I'd prefer to have something like altGlyph but *outside* a <text> element
... so you're not mixing text layed out by the browser and author-positioned text

cabanier: but then you'd need the font

heycam: if you're missing the font or some glyphs aren't there use a box or the undefined glyph

cabanier: there's also entity text
... where you want to map some particular characters to something else
... not sure what the use case is
... but it's in InDesign for the Asian market

heycam: I'm not sure I'm keen on the table idea
... it's nice to have all the character data in the DOM itself
... for AT tools etc.

cabanier: it just gets bigger that's all

heycam: so in PDF, when you select between horizontal and vertical is that something you do on the command that draws the text or is it when you select the glyph

cabanier: it's the encoding, it's either horizontal or vertical

<birtles_> scribenick: birtles_

cabanier: but writing-mode also does top-to-bottom right-to-left
... can all the font formats that can currently be referenced in the web content, do they all identify glyphs by integers?
... I believe so

ed: but not SVG fonts

heycam: ok, so numbers are probably ok
... we just need to come up for a name for the element and the attribute

cabanier: and if you want an n-to-m mapping table you need somewhere to put that

<birtles> scribenick: birtles

heycam: I don't think we need that

cabanier: I just think it's going to get verbose
... so what if you have several glyphs

heycam: it looks like <___ ids="10,1">ab</___>

cabanier: and then you would have offset="20, 40" ?

heycam: I'd rather use x,y,dx,dy for that

cabanier: you shouldn't have to specify *all* the offsets, just the ones where you are tweaking them
... the default spacing should be fine for most cases

heycam: so maybe you want <tspans> for that?

cabanier and ed: no we don't want tspans

heycam: what if you want differently coloured text in the middle?

ed: break it up

heycam: but what about selection and hit-testing
... if you have to have separate elements for different formatting you'd lose the ability to know that it's the same text run

AlexD: I want a javascript function that just gets the text run, I shouldn't have to piece it together

heycam: I think we can easily add a tspan-like element in the middle
... which would also mean you don't have to do <___ dx="0 0 0 0 3 0">...</___> to tweak the position of just a few characters
... typically when you have a font family do they tend to have the same glyph ids?

cabanier and AlexD: they can be all mixed up

heycam: well, you have to know the font when you author it anyway

<Cyril> s/http:\/\/perso.telecom-paristech.fr\/~concolat\/SVG\/streaming\//http:\/\/dev.w3.org\/SVG\/modules\/streaming\/index.html/

AlexD: that's right, that's part of the authoring exercise

heycam: since selections in the document are represented as a DOM selection using a range
... you couldn't do that if you didn't have the character IDs and only had IDs

AlexD: the problem is that if you have a <____> and you have 10 ids and 10 characters, you still can't match up ids to characters for text selection since we don't have the mapping

heycam: so you could only select the whole lot at once
... we could assume some default
... in firefox you can select half a ligature
... can we use something like that as a default
... and then also provide a mechanism if you want something more accurate

AlexD: I think you'll run into all the same problems that face SVG fonts not coping with shaping

heycam: so we need the table

AlexD: the mapping table works better, it's a simple lookup
... and that gives you delineated glyph boundaries that you can use for selection

heycam: so if you have 3 characters mapping to one glyph
... then when you select that glyph you get back those 3 characters

birtles: how do you do the reverse look-up if you have different characters mapping to the same glyph?

AlexD: that doesn't normally happen, but it can

heycam: what does PDF do?

[discussion about the complexities of an n-to-m mapping where one glyph/grapheme cluster can be used for multiple characters and one character/string of characters can be mapped to different glyphs depending on context/author preference]

krit: what if you have an SVG-in-opentype font you might want to select the SVG one or not

cabanier and heycam: they have the same ID, you can't do that

heycam: normally in the DOM the character data is the actual text
... and I think various things expect that to be the case

cabanier: even if the element name is different?

heycam: yeah
... I'm pretty sure AT tools walk the DOM and find character data to read out

cabanier: so we should try to keep those tools happy?

heycam: not only that, but also the DOM selection stuff

cabanier: but if we put it there we cannot do selection

heycam: we can if we resolve how to look up the mapping

AlexD: you can have the table separate and then you don't need the IDs next to the character data

cabanier: what do the AT tools use

heycam: they just walk the DOM as far as I am away
... but that was only one concern
... if you select some text with the mouse
... there's a corresponding DOM range that's indexed by character
... if there's no character data in the DOM, what are you referring to?

ed: you could construct some kind of shadow tree dom ;)

heycam: is there a method on the text selection that gets the character data?

krit: what are use cases?

all: representing PDF in SVG?

birtles: how far does CSS Fonts' font-feature-settings get us with this use case?
... when you want to select a particular variant, use a <tspan> with the appropriate feature?

heycam: it's conceivable but there may be issues if some browsers don't support all the layout features of the given font
... I'd like to have think about how we can still have character data directly in the DOM but have reliable selection of glyphs corresponding to a selection of characters in the DOM without having duplicated information in the table as well as in the character data of the element

<scribe> ACTION: Cameron to think about glyph selection and positioning [recorded in http://www.w3.org/2013/02/04-svg-minutes.html#action22]

<trackbot> Created ACTION-3434 - Think about glyph selection and positioning [on Cameron McCormack - due 2013-02-12].

<heycam> ScribeNick: heycam

global coordinate system

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IFrame_Like_Syntax#GlobalCoordinateSystem

birtles: I'm not sure if I can summarise this well

… you can see that it's about establishing how different tiles map to one another's coordinate systems

… is this useful?

… there are some alternatives listed there

… there are different ways you could use a viewBox, and different ways you could use the coordinates of the child content for the same effect

… you could say that all child content used in the one document is the same coordinate system

… and in the child content if it wanted to represent the data in a different coordinate system it could have its own viewBox

birtles: three different options on how you could author this

… they each have advantages/disadvantages

… for example if you say everything is in a global coordinate system, you introduce a coupling between the child tiles and the parent

… the proposal here is that because each of these 3 alternatives have disadvantages, we should use a globalCoordinateSystem element

… it's also mentioned further on that this would allow different kinds of coordinate systems; ones which are useful for connection diagrams, or one for building plans

alex: the only thing is that <globalCorodinateSystem> applies to siblings, it's different from SVG usually where it would apply such a transform to a group

<stakagi> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IFrame_Like_Syntax#7.13_.27Global_coordinate_systems.27_.28Add_new_section.29

<stakagi> formula: http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IFrame_Like_Syntax#7.13.2_Coodrdinate_Transformation_and_Viewport_Establishment

heycam: why not just have tiles wrap their local coordinate space data in a viewBox or transform that transforms it into the agreed-upon global coordinate system?
... then you don't need a new <globalCoordinateSystem> element
... is there a disadvantage to this?

alex: you need to know in the outer document what the position and size of the tile is, so you can avoid loading it unless it is in view

… this is not possible if you position all of your child iframes at 0,0, with the child content all in the same global coordinate system

heycam: we'll continue discussing this later

<scribe> Chair: Erik

<scribe> Scribe: Various

<scribe> Meeting: SVG WG F2F Sydney 2013 Day 2

<scribe> Scribe: heycam

<scribe> Chair: Erik

<scribe> Meeting: SVG WG F2F Sydney 2013 Day 2

<scribe> ScribeNick: heycam

<scribe> Chair: Erik

<scribe> Meeting: SVG WG F2F Sydney 2013 Day 2

This is scribe.perl Revision: 1.137  of Date: 2012/09/20 20:19:01  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

FAILED: s/cabanier: how is the quality of what is produced? If you have /cabanier: how is the quality of what is produced?/
Succeeded: s/Array v/Array/
Succeeded: s/used to/used too/
Succeeded: s/but the impleme//
Succeeded: s/transformed ref/transform="ref"/
Succeeded: s/in SVG/in HTML/
Succeeded: s/resolution:/RESOLUTION:/g
Succeeded: s/Compositing/SVG/
FAILED: s/shared\?/shared(\?)/
Succeeded: s/birtles/Cyril/
Succeeded: s/birtles/shanestephens_/
Succeeded: s/morening/morning/
FAILED: s/I your/In your/
Succeeded: s/on all tiles/on a given layer/
Succeeded: s/to/too/
Succeeded: s/to/too/
WARNING: Bad s/// command: s/http:\/\/perso.telecom-paristech.fr\/~concolat\/SVG\/streaming\//http:\/\/dev.w3.org\/SVG\/modules\/streaming\/index.html/
Found ScribeNick: nikos
Found Scribe: Cyril
Inferring ScribeNick: Cyril
Found ScribeNick: heycam
Found ScribeNick: krit
Found ScribeNick: heycam
Found ScribeNick: krit
Found ScribeNick: birtles
Found ScribeNick: birtles_
Found ScribeNick: birtles
Found ScribeNick: heycam
Found Scribe: Various
Found Scribe: heycam
Inferring ScribeNick: heycam
Found ScribeNick: heycam
Scribes: Cyril, Various, heycam
ScribeNicks: nikos, Cyril, heycam, krit, birtles, birtles_

WARNING: No "Present: ... " found!
Possibly Present: ACTION-3427 ACTION-3428 AlexD Cyril Cyril_ Tav alex all birtles birtles_ brian cabanier dino dirk dmitry ed erick erik formula glenn heycam https joined jun konno krit krit1 left nikos nikos1 rik scribenick shane shanestephens_ shepazu silvia stakagi stearns stearns_ svg trackbot ys-uchida
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

Found Date: 04 Feb 2013
Guessing minutes URL: http://www.w3.org/2013/02/04-svg-minutes.html
People with action items: birtles brian cameron cyril dirk erik heycam krit rik stakagi