SVG Working Group Teleconference -- 06 Feb 2013

<nikos> RRSAgent make minutes

<nikos> yeh =)

<heycam> nikos, do you have local IRC logs?

<nikos> I'll check.

<nikos> I do. What would you like me to do with them?

<heycam> do you want to just mail them as is as the minutes for the day? too much trouble to get them processed as HTML minutes, I think.

<nikos> Ok, will do

<heycam> thanks

<nikos> heycam, they should be bcc'd to public-svg right?

<nikos> I was messing around with scribe.perl seeing if I could generate something nice out of them but will have to give up for now

<heycam> yep

<heycam> ok, no problem

<heycam> trackbot, close ACTION-3417

<trackbot> Closed ACTION-3417 Relax referencing requirements (issue-2295).

<heycam> Cyril, when you get a chance could you add IDL for the SVGDiscardElement interface to struct.html? the build scripts give me a warning each time I touch that chapter.

<heycam> trackbot, close ACTION-3130

<trackbot> Closed ACTION-3130 Edit the spec. for http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Resolutions#Remove_the_restriction_of_tref_pointing_to_only_an_SVG_document_fragment..

<trackbot> Date: 06 February 2013

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

<birtles> scribenick: birtles

border brushes

cabanier: in CSS you have the border-image property
... where you can slice up an image
... and tile the sides
... you can stretch them and after a point they start duplicating themselves

<cabanier> link: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2013/Agenda/border_brushes

cabanier: we have the same features in Illustrator
... and you can define a side and a corner and it does the stacking for you
... instead of just a png
... if you do a google search you can see many places where people use this
... on the wiki there are several examples

krit: you could use svg

cabanier: but that's kind of hard because you have to define where the border is

dino: do the two images orient along the edge

cabanier: yes
... when there's a curve the artwork needs to bend along the curve
... so you might need to add some limitations
... e.g. if there was a gradient then you'd need to morph the gradient

birtles: so is this for just SVG

cabanier: this is the SVG counterpart to what's in CSS

AlexD: this would have to be an adaptive dashing style thing
... so you have an exact integer number of repeats
... like we talked about for dashing where you try to make the dash array end on exact integers

cabanier: you'd use this brush like a stroke
... so it also is effected by the stroke-width
... e.g. a stroke width of 2 would make it scale by two
... there's an e.g. with dashes
... so each dash would be one of the images

heycam: so, theses dashes here, some of them are squashed when they're small
... but in the non-dashing examples they maintain their aspect ratio

cabanier: I think in dashing examples they either squash or duplicate
... when you apply the corners...
... I think for now we only want this on polygons
... because how do you work out the corner of a path?
... even for rects you know where the corners are

heycam: but you have examples of using this on a path

cabanier: yes, I just drew these in Illustrator
... in the star it uses the corner on the outside but not in the inside
... I think it is a special case for stars

<shepazu> (this corners question applies to the "rounded corners" proposal from Rigi-Kaltbad, too)

dino: are you sure?

cabanier: oh, I think you're right

krit: it looks like the engine looks for the smallest angle
... and orients to that angle

cabanier: I think the syntax for this would be fairly easy
... for rounded corners it doesn't use the corner piece
... that's just how Illustrator implemented it

heycam: is it warping the corner pieces?

cabanier: yes

ed: so if you had a sharp corner in the last example with the squiggly line
... would it get the corner piece?

cabanier: no

dino: so you'd only use it for basic shapes?

cabanier: right

dino: even if you drew the star as a path you wouldn't get the corner piece?

cabanier: yes
... otherwise you have to define what is a corner

dino: seems like there would be a lot of work in describing how you walk a rectangular object...

cabanier: it would be a lot of implementation work but not so much spec work
... I don't think the warping would be defined in the spec

dino: I think how the control points are warped should be defined in the spec
... if you want it to be interoperable

heycam: I think you could have a high-level description regarding how points along the bezier are mapped

cabanier: I'm not saying we don't have to do it.. but do we do that elsewhere in the spec?

ed: yes, we do

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

ed: the method attribute
... when you set that to stretch
... it says something about how its done but it's not very precise

dmitry: I checked and Illustrator does apply the corner pieces to custom paths with sharp corners

cabanier: so it does, you're right

ed: if you make a star with a path you probably want it

krit: there's more calculation to determine if the corner between two curves is a sharp corner or not

ed: where is the cut-off point

krit: maybe it does it on all sharp corners?
... these are fairly detailed discussions...

<heycam> https://svgwg.org/svg2-draft/painting.html#TermLineJoinShape

heycam: the new wording about computing the shape of a stroke has the kinds of descriptions you would want for the warping here
... it's a high-level description of taking points on a path and turning them into shapes or different points

<dmitry> Screenshot of the corner processing in Illustrator: http://cl.ly/image/0h3l0u0D3r1B

cabanier: so this would effect getStrokeBBox too right?

heycam: if some of the tiling pattern didn't fill out the whole tiling space or overflow it, would that effect the stroke bbox?

cabanier: there was some discussion of this in the mailing list
... at least it's easier than other brushes like the bristle brush
... I think this is pretty easy and would be nice to have in CSS too
... in CSS you would just use it like border-image
... and if you applied it to a CSS box you wouldn't have the deformed beziers
... do you think this is useful?

krit: I think this should not go into SVG2

birtles: I agree

krit: so should we continue at all, and if so how should we continue?

dmitry: Illustrator lets you define two different corner pieces (inside and outside corner)

heycam and cabanier: agree it should not be in SVG2

<dmitry> Screenshot of two types of corners: http://cl.ly/image/1S3B3i1l0E0e

krit: so do we want the feature?

heycam: I think we want the feature

krit: do we want to have a module for this or in SVG.next?

heycam: I think it could be a separate spec

ed: sure

<heycam> dino, http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Commitments

RESOLUTION: We will continue developing border brushes in a separate specification

<scribe> ACTION: Rik to create a module to define SVG border brushes [recorded in http://www.w3.org/2013/02/06-svg-minutes.html#action01]

<trackbot> Created ACTION-3440 - Create a module to define SVG border brushes [on Rik Cabanier - due 2013-02-13].

variable width stroke

http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2013/Agenda/discuss_vw_stroke

cabanier: so this is not going to be for SVG2

heycam: but we had the requirement to represent InkML traces in SVG
... we said we'd enable InkML to be rendered
... so we *could* consider it for SVG2

cabanier: defining it is pretty easy
... not sure how hard it is to do in the graphic libraries

heycam: can't be harder than these border brushes

cabanier: at any rate, defining it should be very easy
... you just say that along these paths we have these points and at each point you say, e.g. the stroke should be 200%
... and then you draw a catmull-rom curve along the points

AlexD: why would you do that, when it involves tension

heycam: I'm thinking we could just extend stroke-width itself
... e.g. stroke-width="10px 15px"

cabanier: I think you want to use percentages
... e.g. to represent pressure on the pen
... or if you pick up a bigger pen you want to just say 200%

heycam: (e.g. on the board)
... stroke-width="10px" stroke-width-variation="0px 100%, 100px 100%, 150px 50%"

birtles: (use case from previous discussion) I want this feature to be able to do finger-drawing on a tablet where the stroke width varies with touch pressure

cabanier: I think I prefer stroke-width-varation="0% 100%, 66% 100%, 10% 50%"

krit: do you want to be able to specify different widths for each side (left/right)

cabanier: I think that might get complicated because it might not always be obvious which side is which

heycam: I think it is ok

dmitry: I think if you really want that you can just change the path

heycam: if the widths could be a repeating pattern you could do spaghetti lines
... I don't think it's much more work

cabanier: yes, I agree

heycam: I think you could automatically tile it, especially if your offsets are absolute lengths
... I would actually be ok with different left-right sides
... since I think the implementation difficulty would be the same
... but what if the two intersected?

cabanier: they can't since the percentage is always positive

birtles: is it worth adding the features in stages?
... I think the primary use cases would be data from tablets and calligraphy
... where you probably don't need repeating patterns or asymmetric variations

ed: I think it would be nice to have a spread-method like approach
... where it just repeats
... I think you might want to use variable-stroke width for custom line cap
... where the end tapers off

dmitry: you could use markers for that
... but it doesn't always work

cabanier: like if you have a gradient on the stroke
... the marker would have a separate gradient

dino: who do we expect to use this?
... hand authors? tools to export?
... I think this kind of feature is complex to hand author

cabanier: I think it's not so hard

krit: of course, you can already export this from Illsutrator

cabanier: but strokes become a series of paths

AlexD: cartographers have been asking for this

dmitry: and if the export from Illustrator loses the original path then you can't modify it in script

birtles: and I think there are many uses cases where you create/modify paths from script

Cyril: does this affect markers

heycam: yes
... because markers can be scaled in size depending on the stroke width
... but that's probably what you want

ed: I think there are cases where you don't

cabanier: I think you want the original stroke-width

Cyril: in d3 examples, where you have flows of data
... and you have arrows where you want the arrow to grow or shrink

ed: so how should we proceed?

heycam: if someone is keen to do the work, someone could specify the minimum set of features
... symmetric stroke width variation with no repeating

krit: can stroke-width-variation be a shorthand

heycam: not sure about the naming

cabanier: it could be

Cyril: this would be a presentation attribute?

heycam: as I've written it, yes

cabanier: can you define a URI somewhere

heycam: so you can re-use the definition?
... inheritance works so that might be enough
... at first I'd like to avoid element syntax and just have the property
... if we need a pre-defined thing we can add it later
... it's currently assigned to Doug in the requirements commitments

(item 20)

cabanier: I can talk to Doug about it

<shepazu> (I'm happy to defer to someone else for this, cabanier)

<scribe> ACTION: Rik to specify variable width stroking in SVG2 [recorded in http://www.w3.org/2013/02/06-svg-minutes.html#action02]

<trackbot> Created ACTION-3441 - Specify variable width stroking in SVG2 [on Rik Cabanier - due 2013-02-13].

<shepazu> (also happy to discuss it and give feedback)

<ed> -- 15min break --

-- break, 15min --

<heycam> ScribeNick: heycam

Media fragments and SVG stacks

krit: I'm not sure on the status of media fragments on the <image> element

… especially for xlink:href

… I don't think it's specified in SVG

… should it be combined together with media fragments? allow #xywh there as well? seems to be useful, but it's not specified currently.

… how would that affect our SVG Stacks hack?

ed: I don't think it would affect it that much

… unless you pick that particular ID

krit: there are more fragments that SVG supports that aren't supported in Media Fragments

… choosing the viewport e.g.

… should we talk to the Media Fragments WG people?

<silvia> http://www.w3.org/TR/media-frags/

silvia: what are the other things you're missing?

<silvia> spatial dimensions: http://www.w3.org/TR/media-frags/#naming-space

https://svgwg.org/svg2-draft/linking.html#LinksIntoSVG

ed: you can pass transforms, a viewBox

Cyril: I don't understand how this depends on xlink:href="" spec

krit: Media Fragments conflicts with SVG in some cases

Cyril: I don't see the problem with XLink href

… media fragments are defined by the MIME type

… if you use it in xlink:href="" or src="", it shouldn't matter

krit: we need to reference Media Fragments

ed: I don't think they're in very much conflict with each other

… we should reference Media Fragments

silvia: are you using Media Fragments with SVG resources yet?

ed: no

silvia: SVG resources define how their ID fragments get interpreted, if you don't adopted the Media Fragment spec for that resource type then there's no conflict

Cyril: but it makes sense to support Media Fragments, xywh, or timing as well

silvia: you just need to extend the fragment specification for SVG

Cyril: so t and xywh should be reserved?

heycam: just reserve "t=" and "xywh="

Cyril: in Media Fragments you have four dimensions. how does ID work?

silvia: nobody has implemented that

… the way we envision it is that some containers define names for sections, it's like imagine having a WebVTT chapter file in a webm file, and you have names for sections of the video file

… and you can use the chapter name to address the chapter

Cyril: what's the syntax?

silvia: id=string

Cyril: so it's not "#<string>" it's "#id=<string>"

silvia: yes

krit: for SVG would it be a difference to support #<element> compared to #id=<element>?

Cyril: the question is how to combine them

… once you start using a freeform name, you can't use an "&" and follow it with another dimension

silvia: we wanted to be able to support multiple dimensions; choose this one video segment (temporal), and then choose a spatial area

… that's why we defined the parsing for these media fragments

… if you don't do that from the start it's difficult to post-fit it

… your selectors are functions?

… you could do something like "#mediafrag(xywh=…)" to be compatible

Cyril: you'd have to treat SVG differently then

… sometimes you don't know what the type of the resource is

krit: do all media fragments require an equals sign?

silvia: yes

krit: then it's probably fine

… we shouldn't need to have #mediafrag

Cyril: we could disallow ampersand in SVG IDs, then it combines well here

krit: media fragments in HTML, if you have <img src="blah#xywh=…"> you would have the same problem yes?

silvia: on HTML pages it's difficult, since HTML has specified the way a fragment is interpreted

… often you have a custom web site, e.g. in YouTube you can have similar time offsets with fragments

… but that's not what we've standardised for

… we've done this only for media files

… HTML is a different media type

krit: depends on the MIME type of the document you reference?

silvia: yes

… that's how the URL specification has defined fragments to work

krit: so we need to specify how SVG's fragments are interpreted
... the timing fragments are useful in SVG too yes/

ed: we should define how that works

birtles: we've said for Web Animations we want this to work

… would be good if this worked for HTML containing documents with animations as well as SVG

Cyril, http://www.w3.org/TR/2006/REC-xml-20060816/#NT-Name

dino: Cyril is asking how you distinguish #t=… from normal ID references in HTML

Cyril: if HTML doesn't use the same solution as us, disallowing "&" and "=", it wouldn't be good

krit: same problem with SVG in HTML, the MIME type is text/html, and the fragments would work differently

silvia: the HTML MIME type does not support media fragments

Cyril: yet?

silvia: I think it's unlikely

ed: but if we have Web Animations it might be useful

silvia: we discussed xywh for HTML, it might be an interesting feature, but the HTML WG should discuss that

Cyril: so should we aim for alignining with other media-like resources, or what HTML supports?

silvia: I'd go with both strategies

… I would want to be as much compatible with that spec as possible, and when SVG goes forward have its MIME type define how media fragments work, it's a bigger argument for HTML to support it

… I don't think this will break SVG documents, but with HTML it could well break pages

… people might have used #t= to mean something different on HTML pages

… I would orient myself towards that problem, but rather being compatible with other media files

krit: so Media Fragments defines how xywh are parsed, why do we need to define that in SVG?

Cyril: we just need to say image/svg+xml follows media fragments

silvia: right

… the Media Fragments working group was bound by the URL specification

… fragments are defined interpreted based on the mime type

… we didn't want to have to deal with all of the mime types around, just video

krit: SVG is still based on IRI, which should allow more characters

silvia: it's not a problem; we wrote the spec to be based on UTF-8

… the only place where it really mattered was the chapter names, named references

heycam: I think the URL Standard is meant to supersede IRIs

Cyril: I think I'm fine with the group saying we adopt media fragments, and we restrict our IDs not to include xywh=, ampersands, etc.

… and then later can coordinate with HTML WG to see if it's possible for them to support this too

silvia: one part of the Media Fragments spec has been included in HTML; it defines how time offsets in videos are interpreted

Cyril: if you put t=15 does the document timeline start at 0?

birtles: it does a seek

… then we need to add automatic pausing

RESOLUTION: SVG 2 will use Media Fragments.

<scribe> ACTION: Cyril to add Media Fragments support to SVG 2. [recorded in http://www.w3.org/2013/02/06-svg-minutes.html#action03]

<trackbot> Created ACTION-3442 - Add Media Fragments support to SVG 2. [on Cyril Concolato - due 2013-02-14].

Cyril: is #svgView(viewBox()) the same thing as #xywh?

ed: not quite

<scribe> ACTION: Brian to define how #t= is interpeted in Web Animations. [recorded in http://www.w3.org/2013/02/06-svg-minutes.html#action04]

<trackbot> Created ACTION-3443 - Define how #t= is interpeted in Web Animations. [on Brian Birtles - due 2013-02-14].

… percentages will be different

krit: for #xywh these reference the original viewport

SVG/CSS Matrix harmonisation

krit: we have a new function that gets the transform between two elements

… I think this will be harder with CSS transforms

… since they have 3d transforms

… and it's not really possible to get a transformation matrix over this flattening

… the question is how do we want to solve this

… and second, it returns an SVGMatrix which is 2D

… it's not applicable for this

… it should return something that can represent 3D matrices

… I spoke with Dean about flattening

… we think that it should either give you an exception, a null matrix back...

… somethign that indicates it's not possible to get the transformation

… something to be resolved is the return type

… we would need to specify a new matrix

… CSS Transforms had a spec for it

… which needed to be removed, since it uses CSS OM

… Dean proposed Matrix4x4

… we didn't know at this time where it should live -- maybe in ECMAScript?

… on the window object

… what does it look like?

<krit> http://lists.w3.org/Archives/Public/public-fx/2012JanMar/0007.html

krit: there were some discusisons about whether it should work with Euler coordinates

dino: there was some discussion that day in the SVG meeting about this

… which I never followed up on

… I think it was about whether to use radians or degrees

… we have methods on here for both modifying the matrix and returning a new one

… the other big discussion was someone suggested it should really be an ECMAScript type

… someone else discussing whether it shouldn't have all those exposed as attributes, it should be a typed array with a wrapper of some sort

krit: they wanted to use it with WebGL as well

… which needs to be fast

dino: that's why I have copyIntoFloat32Array

… but you might not want to call this function each time

heycam: I don't think there's a concept of live typed arrays is there?

dino: I think the suggestion was to have the typed array backing the matrix

… there would be an attribute to access that matrix backing data directly

… in WebGL it would just be a matter of getting that out, instead of constantly creating new typed arrays

… we didn't really have strong drive to get this happening quickly

… but I think we do now, now that the spec is closer to completion

heycam: makes you think well then why not about Points, etc.

dino: I think that's why it wouldn't make sense to send it to ECMA

… if we just have Matrix

dino: there is still more work to do with improving SVG DOM interfaces

… should we add something now to expose 4x4 matrices

… or have conversion functions separate from the SVG DOM

heycam: could we not replace SVGMatrix with Matrix4x4?

dino: that was the idea

krit: we got everything from SVGMatrix on Matrix4x4, then we make SVGMatrix inherit from this one

… there are some things that need to be in SVGMatrix

http://www.w3.org/TR/SVG/coords.html#InterfaceSVGMatrix

krit: there are SVGExceptions being thrown

heycam: that's gone in SVG2

dmitry: nobody uses skews

cabanier: why does this issue keep coming up then?

krit: Mozilla found some pages that did use skew

dino: people use it for horrible fake 3d, isometric

dmitry: we should encourage them to not do this by not having it in the specification

cabanier: I know people use skew a lot in animations for fake 3d

krit: we could strongly ask people not to use it...

dmitry: it should be easier to make beautiful things, not just easier to make ugly things too

krit: we could have them be deprecated but browsers still implement it

dino: I don't think we can remove skews from transform syntax any more

… do we need to expose them in this interface?

krit: yes

dino: sounds like we do if we want to replace SVGMatrix with Matrix4x4

ed: so do we need to fix this in SVG2?

krit: do we want to go with this new interface? I think yes

… if it should live in ECMA we can worry about that later

… whether it should go on window I asked the CSS group for approval

heycam: I think just leave it not [NoInterfaceObject]

krit: which spec should it live in? a new one?

cabanier: Canvas references SVGMatrix, would be nice to reference this instead

krit: what happens if you have a 3D transform on canvas?

heycam: who should write this Matrix4x4 spec?

krit: have to ask first, but I will probably do it

dino: what about the name Matrix4x4?

heycam: eh...

dino: GL calls them matrix4, vec3, etc.

krit: i prefer Matrix to Matrix4x4

heycam: should Matrix replace SVGMatrix, or SVGMatrix inherit?

ed: I don't think it's common for people to rely on "[object SVGMatrix]" being the actual object type

krit: ok, just replace SVGMatrix with the new Matrix then

ed: as long as we have the same method names I think it should be fine

RESOLUTION: SVG 2 will reference the new Matrix specification and replace SVGMatrix with Matrix, once that spec is ready.

<scribe> ACTION: krit to write up a spec for Matrix [recorded in http://www.w3.org/2013/02/06-svg-minutes.html#action05]

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

<scribe> ACTION: dirk to write up a spec for Matrix [recorded in http://www.w3.org/2013/02/06-svg-minutes.html#action06]

<trackbot> Created ACTION-3444 - Write up a spec for Matrix [on Dirk Schulze - due 2013-02-14].

ACTION-3444: Also update SVG 2 to reference the spec when it's ready.

<trackbot> Notes added to ACTION-3444 Write up a spec for Matrix.

Changes to Filter Effects and Custom Filters

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

krit: custom filters are used with CSS shaders

… so that you can apply some distortion/modification to the graphics

… in the old specification, the syntax was "custom(url('vertexshader') mix(url('fragmentshader') multiply src-over), 4 4 attached, param1 value1, param2 value2)"

… it's very long, hard to read, and only supports GLSL

… MS asked us to make it more generic to support other shader languages

… one idea is "custom()" references an at-rule

… @filter f1 { … }

… but this does not support animations

dino: you could have @filter f2 { … } and animate between f1 and f2

krit: we wanted to try to keep it simple

… the @filter rule tries to emulate @font-face

… so it has a 'src' attribute, and you can provide a type

… src: url(…) format("x-shader/x-vertex")

heycam: these are just hints not to download, like @font-face?

krit: no it's different from font-face

… you need all of these resources

… there's also "geometry: grid(4,4);"

… and "margin: …;" like a filter primitive margin

… and "parameters: …;" for the parameters to the shader programs

… so what happens with different shader formats.

… the @filter defines a generic primitive, so this is not limited to CSS Shaders

… if you don't support GLSL, we'd suggest a new media query

… @media (filter: glsl) { … }

… so other browser could define new properties on the at rule

ed: what is the point of the format() yet?

krit: in case there is a new shader type under GLSL

dino: WebGL defines a restricted version of GLSL

… it's not strictly GLSL

krit: maybe this keyword could be "WebGL" then

… we can think about that later

ed: so you have src with format()s in case you support more shader types later?

krit: also you could reference an SVG filter here

</filter>

… something like SVG Parameters or CSS Variables

… the custom() function would then reference a filter at-rule that references the SVG filter

@filter g2 { src: url(#f2) format('svg'); parameters: x1 30, x2 30; }

filter: custom(g2, x1 20, x2 20);

ed: what is the var() syntax there? is that defined somewhere?

krit: we're not going to put that in the first version of the spec

… since it's not clear how Parameters / CSS Variables is working in SVG yet

… but this is how custom SVG filters can be animated in the future

ed: it might be useful to be able to pass in the document time into the filter

krit: we can think about that for v2

heycam: I find it a bit strange that format() in src works differently from in @font-face

krit: what if we rename "src" to "filter-src"?

heycam: maybe… it might be the combination of "src" and "format()" that looks to me like formats are hints to avoid downloading

… why require format() at all given you can look at the actual served Content-Type?

krit: servers might not set that correctly

dino: there's not even a standardised extension for these files

… what if you reference from the local file system

heycam: what is the advantage of 'src' having the same format across different shading language @filter rules?

dino: the source language format is the thing most likely to change

… geometric, margin, parameters make sense with other shader languages too

krit: so are people happy with @filter rule?

heycam: I like it more than stuffing everything in to the property

… what about the src descriptor, people want a different name?

Cyril: you plan to have different mime types for vertex vs fragment shaders?

krit: it's the case already

… that's defined by WebGL

Cyril: is the mime type registered?

dino: x-shader/* is not registered, but someone would have written something down somewhere

heycam: for me, you don't need to rename src for now…

RESOLUTION: Filter Effects changes to use @filter.

-- lunch break one hour --

<cabanier> scribenick: cabanier

heycam: filter media query feels different from other media queries

…since those are properties of the device

ed: maybe @supports?

heycam: so you could write '@support filter(glsl)'

… the syntax is extended but not implement

krit: yes, that seems better
... I'm OK with that

heycam: at some point there will be @supports for @-rules

krit: inside the rule?

heycam: you could then have:

… atrule(filter, src:… format('x-shader')

… the normal properties just check if they parse correctly

… so maybe it's not quite right, but I'd be happy

… Maybe email www-style

<scribe> ACTION: Dirk to email www-style about at-supports filter function [recorded in http://www.w3.org/2013/02/06-svg-minutes.html#action07]

<trackbot> Created ACTION-3445 - Email www-style about at-supports filter function [on Dirk Schulze - due 2013-02-14].

krit: is @filter-rule fine?

ed: are there other possibilities

… is everything of the previous syntax possible

krit: yes

cabanier: even animations:

heycam: that's for the @media part not the rule

krit: do we need a new RESOLUTION?

heycam: can you do the same as before?

krit: yes

RESOLUTION: accept proposed descriptors for at-filter rule

CSS OM and SVG DOM improvements; exposing calc values

heycam: the question is if we support css lenght and how we reflect that in svg

… Dirk, did you add it already?

krit: yes. as unknown because we don't want to extend SVG DOM at this time

heycam: so, there are a few new unit types such as rem, vw, vh, ch, etc

….rem is default font size

shanestephens_: it's to do layout based on the font

heycam: for instance to do margins

shanestephens_: MDN has a good description

heycam: we want to support all of those

… my question was that we want to add accessors for all of those

krit: should make it so that it becomes more extensible

heycam: you could use named properties

… that makes it open ended. But you'd have to update the spec

ed: that makes it more clear that the spec is going to be extended

… having a group of names makes that more clear

… the spec refer to the group of supported unit types in CSS

heycam: named properties would require slightly different implementation

… but I like them to be visible in IDL

ed: as long as the spec is clear that they can be updated, it's fine by me

heycam: I think we want an accessor so you can set it by string

… .x.? to get the string value

… to write or read the string

… .value ?

shanestephens_: I like that

… value would be a strange name for a unit

RESOLUTION: add a 'value' attribute to read or write the CSS serialization of a unit length

heycam: there are values like 'calc' and 'attr'

krit: x = attr('x')

heycam: that would work

krit: that depends on the css syntax so it would not fail parsing

heycam: no. that would not be a problem.

… you can have a property to looks at attr(style) and that would fail to parse

… do we want calc and attr and var to work in SVG?

krit: yes

heycam: and have them work on x and y to work on CSS

shanestephens_: if something is a calc?

heycam: you can still look at 'px'

… should there be an accessor to get the calc value?

shanestephens_: we have a lot of experience with polyfill and we spend a lot of javascript mimicing value parsing

… web animations has a calc in javascript parser

heycam: the other half is how this is reflect in SVG length

… and follow Dirk's example to reflect them as unknown values

ed: yes, that is the only reasonable value

<scribe> ACTION: heycam add a string accessor on SVG animated length and to make 'calc', 'attr' and 'var' work [recorded in http://www.w3.org/2013/02/06-svg-minutes.html#action08]

<trackbot> Created ACTION-3446 - Add a string accessor on SVG animated length and to make 'calc', 'attr' and 'var' work [on Cameron McCormack - due 2013-02-14].

heycam: I changed the spec that if there is a list, you just set the first value

… if there is no value, we add one

ed: sounds reasonable

heycam: I didn't add anything to SVGAnimatedAngle

… since noone is really using that one

… everyone uses the length one

cabanier: maybe better to be consistent

heycam: OK

<scribe> ACTION: heycam to update SVGAnimatedAngle as well [recorded in http://www.w3.org/2013/02/06-svg-minutes.html#action09]

<trackbot> Created ACTION-3447 - Update SVGAnimatedAngle as well [on Cameron McCormack - due 2013-02-14].

Web Animations

<birtles> https://dvcs.w3.org/hg/FXTF/raw-file/default/web-anim/index.html

birtles: there are 3 documents

… the link is the core spec and the intent is to have 2 more document to map SVG and CSS features

… Is Tab's work available yet?

shanestephens_: it's not quite ready, but I'll provide a link

<shanestephens_> This is a copy of the CSS integration document, but it does rely on features that are not yet firmed up in the core specification: https://docs.google.com/document/d/1CrfospthGnMg3tXmYYnZmRDE8Re-uL4mGkuSB0VPcTA/edit

birtles: we have f2f next week

shanestephens_: there's a few reasons that the spec is so big

… we need to provide IDLs and Brian added a lot of diagrams

… and complete descriptions of processes

… Also we have a fairly complete polyfill that is only using 1700 lines of code

krit: does the polyfill do synchronisation?

shanestephens_: yes, but it doesn't integrate with CSS and SVG

… but it works with other libraries

<shanestephens_> here is the polyfill: https://github.com/web-animations/web-animations-js

birtles: there's a skeleton for the SVG integration

… but don't even look at that

… I want to talk about scheduling

<shanestephens_> (actually it's now about 2200 lines)

… next week we have a f2f to fix remaining issues

… and then request FPWD

… there are 3 contentious features

shanestephens_: except for video, the main thrust of the doc is correct

birtles: the FX taskforce will be asked to review so we can publish it

… and we hope to do that at the end of next week

shanestephens_: the review will be 2 ways. People will either like it or there will be a lot of contentious issues

cabanier: probably have to ask each group for resolution

birtles: yes

dino: It would like to know what changed since I provided feedback

… a declarative form is more important and it's not in the document

… I notice that the template is taken so that's good

shanestephens_: for declarative, we would like to CSS animation, transition and SVG all work the same under the hood

dino: yes

shanestephens_: so that in future version we can push more declarative markup in the spec

dino: OK. Then I have no problem with the model and it does a good job of describing what an animation engine does in a browser

… my concern is with the really big javascript API

… CSS transitions became popular because they're powerful without being complex

… people are hesitant for massive APIs

Cyril: authoring tools are missing

shanestephens_: it's a lot smaller than SMIL

… the shim that we built is really quite small

… another things is that it provides a declarative view

… It's really very similar to CSS

… I understand that that doesn't address your concerns

… the polyfill is mostly for testing

s/poylfill/API/

krit: in theory SVG and CSS animations should have the same model under the hood

… the most important part is that this provides an animation model that is currently lacking in CSS

birtles: there's an appendix https://dvcs.w3.org/hg/FXTF/raw-file/default/web-anim/index.html#webidl-ref

dino: that's still really big

birtles: we can talk about things that shouldn't be exposed

dino: A lot of this stuff is needed

… an author wants to provide timing to a document

… he wants things to happen at certain times

… for example, read long books

… where we want something to happen at a certain time

… just that alone, is requested a lot more than low level access to an animation

… scrubbing animation, querying animations, etc

… but we get almost no request for something like this

shanestephens_: In Google we could use this a lot

dino: but most people want simple features

shanestephens_: chaining animations is low level?

dino: it would be great to have that.

… We're on the fence about that one

… I'm not saying not to provide this

… having such a massive API as step 1 seems too much

shanestephens_: Are you suggesting not to provide a JS API?

dino: no, put more emphasis on the integration specs

… step 1, describe the timing mode and the next step is to provide the integration spec

shanestephens_: we think that the most important thing is CSS and SVG animations use the same model

… so we agree with you

dino: I would like to solve of an author that want to make an animated page

… and this API is not a solution for that

birtles: yes, this is not for authors

dino: that is why I want those specs at the same time

shanestephens_: should we have the spec ready at FPWD time?

dino: yes, but not have such an extensive API

krit: CSS animations and transitions need a model now

AlexD: maybe we need to split the APIs into a separate document

dino: ???

birtles: there is a way to split things up in 2 parts

dino: yes, the timing object would allow you to write your animations

birtles: that concept is already there

shanestephens_: that sounds exciting

… do you think the CSS WG would go for that

dino: if you have a class '::timeactive'

… and have a CSS animation in there

… that would be very powerful

birtles: we can do a timesheet

… and I would love to do that

shanestephens_: so we should split the IDL off and into 2 pieces

Cyril: yes, the size is an issue

… maybe splitting the spec in separate documents

birtles: I don't know how that would help

Cyril: setting time in a document is useful by itself with no animations

… media elements could be hooked to that

birtles: those use cases are already met

… you can have a media element

Cyril: you can't have frame accuracy today

… so maybe one step is solve this problem

birtles: it's hard to prioritize

… I'm happy to split the API up

… with regards to the size, we can work on that

… but our problem is that we want to harmonize CSS and SVG

… and we're cutting out a bunch from SMIL already

… so, it will always be big

Cyril: how can you integrate inconsistent models?

… if you map the models, will it break anything?

birtles: no

shanestephens_: CSS is underspecified

birtles: and inconsistently implemented

<birtles> (that is, some details of SVG are inconsistently implemented)

shanestephens_: would it be OK to delay ::timeactive?

… or should we do that now

dino: I would like to have that now and can write something up

… it would be very useful to a lot of people without exposing a large API

… I would like to reimplement CSS animations in WebKit with your spec

… take canvas for instance that took 8 years and only 2 classes

<Cyril> ack

silvia: introducing a big new feature using CSS, SVG and even HTML, how much overlap is there with HTML?

… also when you're introducing this big thing, it's not enough and too much. Since people come with their own angles

… for an HTML person it's not enough but the spec is too big

… splitting it into more document will help

… also providing examples and summaries is very helpful since it's too hard to digest

birtles: there are no changes to HTML

… just additions to document and element interfaces

silvia: how about animateColor. That is in the spec

birtles: that's surprising

shanestephens_: it's tricky

… people say it's too much but want more features

… we should stick to the brief that we want to unify CSS and SVG animation model

silvia: the minute you introduce the API you can animate an HMTL page

Cyril: I want to make sure that we can integrate with media elements

silvia: you can touch the HTML spec if it's needed

… there's an interface that will be needed

dino: <par> and <seq> would be nice to have in the document

… and it's simpler than javascript

… I would like to style animation

shanestephens_: what is the next step?

… we're working on this full time

… and a lot of engineering time to make this happen

dino: where do we want to be in order to make a first draft

… I think the integration document is the most useful

birtles: how can you have that without a model?

ed: yes, I would like the integration specs first

silvia: I would like to see the markup to see what you're trying to do

shanestephens_: this doesn't really apply here

… providing examples in markup will not do

krit1: it seems like we're going in circles

Cyril: everyone agrees that there should be a unified model

… at a minimum we should have the model and integration with CSS

krit1: are timesheets important?

dino: I would like to

… I think those are more important

birtles: I think we can already do that

Cyril: I would like to integrate with media elements

<ed> -- 15min break --

<heycam> ScribeNick: heycam

Web Animations continued

shanestephens_: I had a suggestion that we could keep the parts of the IDL that expose the behaviour of animations generated by CSS and SVG, and remove parts of the IDL that let you create content through js

… so we can test the CSS and SVG are in the same model and are the same thing

… and then cyril can go forward with animations in HTML

… and dean can go forward with timesheets

… and we can look at completing the js api

… I think Brian is interested in adding functionality to SVG

birtles: I'll work on SVG integration

shanestephens_: v1 of the document can be the model, CSS integration, SVG integration, and just enough IDL to confirm that all of the timing parameters of the model are working correctly

Cyril: a browser will be compliant to the standard if it exposes the right objects with the right values at the right time

shanestephens_: that's pretty much all we care about. functionally that the two specs are aligned.

birtles: I don't really like exposing a read only model like that. I think we should split the API into a separate spec.

shanestephens_: it wouldn't have to be read only, but you'd need to leave out things like play()
... the only problem I have with splitting out the API is that it leaves nothing testable

… and if it's not testable, it can't be a spec

birtles: maybe that's OK

… and we publish the API later and test that

dino: a NOTE can go onto the REC track

birtles: I think we can still work on the API spec, it's not sidelined

… I think we're going to implement it anyway, just pref it off

… just having a read only API doesn't meet those use cases

shanestephens_: why do we want to get it to FPWD?

birtles: I think we want to get rid of the animations stuff from SVG and point to this thing

… that's where this whole discussion is going in terms of FPWD

… is this going to be a problem for SVG?

… SVG is moving along, and this one is slowing down

… we've got to work out how to solve that

shanestephens_: if we make it a NOTE would that work?

birtles: we still have the SVG integration document and that will be referenced by SVG 2

shanestephens_: the CSS integration document will only allow you to test that CSS transitions

birtles: what's the whole point of having a unified model, to think out loud?

silvia: from what I'm hearing, you can't have a unified model without the JS API?

shanestephens_: you can't test that it exists without a handle on it

… another way forward would be as part of the spec, specify some interoperability primitives between SVG and CSS

… so have some SVG animations using CSS key frames for example, and vv

… but that's getting in to new features

heycam: you could test how CSS and SVG animations interact

shanestephens_: so a model document that says how CSS and SVG animations exist in the model and how they interact

… then you can test the results of that

birtles: this is not testing much of the animation model

shanestephens_: can we just expose TimedItem?

birtles: it's almost more meaningful to allow CSS animations to have an absolute start time

… in terms of unifying the two

… then at least you know they're working off the same clock

shanestephens_: that doesn't make them interoperable at all though
... exposing TimedItem as a r/w object...

birtles: we could think about that next week

… if you do that I think you might draw in the rest pretty quickly

Cyril: you might want to see if people agree with the model by implementing something

heycam: I think it would be fine to go along the REC track, perhaps with conformance classes on other specifications using the model spec

… you don't need a test suite to pass CR

… though you could just wait until you have feedback from implementors that they are happy with re-jigging their animation implementations in terms of the model

shanestephens_: you could point to the API spec and suggest that as a way for them to test it internally

silvia: people won't be excited about a model spec

shanestephens_: I think we're pushing the model faster so that it can be normatively referenced

… the API can still stay as an ED next to it and publicise it

… brian, dean and I are the people likely to implement in 3/5 browsers, so it's not like the people who need to see this aren't seeing it

Cyril: will MS start implementing this now that there's a unified model?

dino: wonder if a polyfill running in IE is enough to count as an implementation

Requirements reevaluation continued

[65] Have unknown elements treated as <g> for the purpose of rendering

AlexD: useful for globalCoordinateSystem

heycam: I've never been entirely comfortable with changing the behaviour here

ed: I don't like it at all

shanestephens_: Web Components is like a subset of unknown elements

… is that going to end up in SVG as well?

heycam: they rely on unknown elements being rendered?

shanestephens_: we'd need to look at exactly what they rely on

… it's only a subset of unknown elements <x-blah>

<dmitry> *http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Commitments*

heycam: it would be nice to have explicit wording about exactly what is required of unknown elements

ed: I don't know if it makes sense to separate elements found outside of <text> from text content elements

… that's what you typically get from unknown/fallback

Cyril: in previous minutes we said it could be a fallback for connectors

… a new implementation will implement connectors, and a previous one would ignore it

krit: do we have something in mind that we want to add new graphical elements in the future?

… if we wanted introduce a <brush> element as a new resource, this wouldn't work as expected

… for browsers who implement this unknown element, they would render the <brush> contents

… but those who do implement it would not render it

ed: I think it makes more sense to ignore / not draw unknown content

krit: I think it will harm more than solve problems

RESOLUTION: We will drop the unknown-elements-are-rendered requirement from SVG 2.

<scribe> ACTION: Cameron to clarify the behaviour of unknown elements in SVG 2. [recorded in http://www.w3.org/2013/02/06-svg-minutes.html#action10]

<trackbot> Created ACTION-3448 - Clarify the behaviour of unknown elements in SVG 2. [on Cameron McCormack - due 2013-02-14].

[66] Remove the requirement to have @width and @height on foreignObject

<shepazu> (I think this was a mischaracterization of the "unknown elements" proposal)

heycam: this was to make foreignObject sized by shrink wrapping based on its contents

dino: the width will be based on the viewport in HTML

… doesn't make sense for it to be wider than that

krit: once width and height are properties, we have the auto value

… but we should keep the 0 width/height defaults

heycam: it's not something I feel strongly about

ed: I'm fine with not doing anything for this one

RESOLUTION: We will drop the "foreignObject can be automatically sized" requirement for SVG 2.

[67] Improve the fallback mechanism using switch

Cyril: is this similar to allowReorder?

ed: this is how you treat unknown elements

… if you want to switch on something that is a new element, then you won't check the conditional processing attributes

… that's the issue

… let's say we introduce a new <foo> element in SVG, in old user agents you'd still like to see if the new feature string is there, and do something special

… <foo requiredFeatures="blah">

heycam: you could just wrap it in a <g>

ed: that's the workaround

… maybe in some cases you don't want to have some wrapper element

krit: if unknown elements are ignored, then you cannot reference it

ed: render it

heycam: I say just look at those conditional processing attributes if the element is in the SVG namespace

ed: currently a <switch> would always pick an unknown element, since it is considered not to have any conditional processing attributes, and therefore passes the tests

Cyril: you should never pick the element you don't know, what's the sense in that?

ed: either you check the attributes you already know on SVG elements, or you just ignore them

Cyril: so just remove it for the purpose of switch processing

ed: the only way you can get what you want is to wrap it in a known SVG element

<scribe> ACTION: Erik to do the "Improve the fallback mechanism using switch" requirement. [recorded in http://www.w3.org/2013/02/06-svg-minutes.html#action11]

<trackbot> Created ACTION-3449 - Do the "Improve the fallback mechanism using switch" requirement. [on Erik Dahlström - due 2013-02-14].

RESOLUTION: Keep the "Improve the fallback mechanism using switch" requirement in SVG 2.

[68] Provide a way to control audio level and playback

heycam: sounds like we should get this behaviour from the HTMLAudioElement interface

… so I don't think SVG needs anything specific

ed: the previous discussions didn't include <audio>, but I think they should be

ACTION-3432: Should also add <audio>.

<trackbot> Notes added to ACTION-3432 Edit SVG 2 to add the iframe, canvas, video elements.

RESOLUTION: The "Provide a way to control audio level and playback" SVG 2 requirement does not need any action, as we will get this functionality from HTMLAudioElement.

[69] Provide positioning information in MouseEvents

AlexD: returning a user space position

heycam: I thought I had a proposal on SVGPoint to get the UIEvent's position in a given element's coordinate space

krit: I'd like to not encourage SVGPoint but rather a more general Point that's being discussed in CSS

heycam: the problem is UIEvent is not really defined by us
... I'll take the requirement

RESOLUTION: We will keep the "Provide positioning information in MouseEvents" requirement in SVG 2.

<scribe> ACTION: Cameron to do the "Provide positioning information in MouseEvents" SVG 2 requirement. [recorded in http://www.w3.org/2013/02/06-svg-minutes.html#action12]

<trackbot> Created ACTION-3450 - Do the "Provide positioning information in MouseEvents" SVG 2 requirement. [on Cameron McCormack - due 2013-02-14].

[70] Support CSS3 Color syntax

ed: this one already done

[71] Support CSS3 image-fit

ed: got renamed to object-fit
... I'll keep that, if I have the time to do it

<scribe> ACTION: Erik to do the "Support CSS3 image-fit" SVG 2 requirement. [recorded in http://www.w3.org/2013/02/06-svg-minutes.html#action13]

<trackbot> Created ACTION-3451 - Do the "Support CSS3 image-fit" SVG 2 requirement. [on Erik Dahlström - due 2013-02-14].

RESOLUTION: We will keep the "Support CSS3 image-fit" SVG 2 requirement.

[72] Make it easier to write a zoom/pan widget, possibly by adding convenience method to get scale/transfer

heycam: so we discussed in zurich possibly extending CSS overflow and tying zoom/pan to that

… Tab was interested in this

… but it does not exist as a proposal yet

… and needs more thought

… I say defer unless there is a concrete proposal

ed: yep

RESOLUTION: We will defer the "Make it easier to write a zoom/pan widget" SVG 2 requirement unless a concrete proposal is forthcoming.

[73] Align with CSS Value and Units

heycam: I'd like to take that one

<scribe> ACTION: Cameron to align SVG 2 with css3-values. [recorded in http://www.w3.org/2013/02/06-svg-minutes.html#action14]

<trackbot> Created ACTION-3452 - Align SVG 2 with css3-values. [on Cameron McCormack - due 2013-02-14].

RESOLUTION: We will keep the "Align with CSS Value and Units" SVG 2 requirement.

[74] Deprecate baseline-shift and use vertical-align

heycam: contingent on me rewriting the whole Text chapter

… I will keep it

RESOLUTION: We will keep the "Deprecate baseline-shift and use vertical-align" SVG 2 requirement.

[75] Allow video elements to have captions, tracks, etc

krit: I don't know why I put my name there

heycam: should be part of Takagi-san's action, given he is adding <video>

krit: so <track> and <source> would both be SVG elements as well

ACTION-3432: Should also add <track> and <source>.

<trackbot> Notes added to ACTION-3432 Edit SVG 2 to add the iframe, canvas, video elements.

RESOLUTION: We will keep the "Allow video elements to have captions, tracks, etc" SVG 2 requirement.

[76] Allow clip to reference any element

heycam: Chris' name is on that currently

krit: the problem is you have a <g> with a <rect>, why should that not clip while a plain <rect> would clip?

… I don't think this would be a huge problem for anyone to implement

heycam: if you have an existing shape, you don't want to duplicate it to put it in a <clipPath>

krit: I'm not against it but I am not interested in doing the spec work

cabanier: I will take it

birtles: we already have a resolution to allow a <g> in a <clipPath>

<scribe> ACTION: Rik to allow the clip-path property to reference non-<clipPath> elements in SVG 2, and to allow <g> in a <clipPath>. [recorded in http://www.w3.org/2013/02/06-svg-minutes.html#action15]

<trackbot> Created ACTION-3453 - Allow the clip-path property to reference non-<clipPath> elements in SVG 2, and to allow <g> in a <clipPath>. [on Rik Cabanier - due 2013-02-14].

<birtles> http://www.w3.org/2012/01/13-svg-irc#T03-58-11

RESOLUTION: We will keep the "Allow clip to reference any element" SVG 2 requirement.

[77] Promote some attributes to properties

krit: so this is just allowing auto for lengths etc.?

heycam: this is the whole property promotion change

… unless somebody puts their hand up, defer

krit: leave it in the list and see if we have time for it later
... I just know I won't have the time in the next few months to look at this, maybe after it

heycam: how about I put your name next to it

krit: ok

<scribe> ACTION: Dirk to do the "Promote some attributes to properties" SVG 2 requirement. [recorded in http://www.w3.org/2013/02/06-svg-minutes.html#action16]

<trackbot> Created ACTION-3454 - Do the "Promote some attributes to properties" SVG 2 requirement. [on Dirk Schulze - due 2013-02-14].

RESOLUTION: We will keep the "Promote some attributes to properties" SVG 2 requirement for now, and hope Dirk gets time to do it.

[78] Have an advance font metrics interface

heycam: seems deferable to me

dino: what does this mean? isn't there a measureText API in canvas?

ed: that's usable for SVG as well
... if we don't have to do anything that's good too

cabanier: I'm not sure if people are happy with that API

dino: if you can defer something to another group, and they're actually going to do it...

ed: what kind of things does it give you?

dino: the descender lengths, ...

cabanier: font bounding boxes, widths

RESOLUTION: We will defer the "Have an advance font metrics interface" to the canvas spec.

<scribe> ACTION: Rik to investgate making the canvas font metrics interface without needing a <canvas> element. [recorded in http://www.w3.org/2013/02/06-svg-minutes.html#action17]

<trackbot> Created ACTION-3455 - Investgate making the canvas font metrics interface without needing a <canvas> element. [on Rik Cabanier - due 2013-02-14].

ACTION-3455: Maybe by making TextMetrics take a constructor with a text string, element context for style.

<trackbot> Notes added to ACTION-3455 Investgate making the canvas font metrics interface without needing a <canvas> element..

-- finish --

- DRAFT -

SVG Working Group Teleconference

06 Feb 2013

Attendees

Contents

border brushes

variable width stroke

Media fragments and SVG stacks

SVG/CSS Matrix harmonisation

Changes to Filter Effects and Custom Filters

CSS OM and SVG DOM improvements; exposing calc values

Web Animations

Web Animations continued

Requirements reevaluation continued

Summary of Action Items

Scribe.perl diagnostic output