SVG Working Group Teleconference -- 18 Feb 2009

<trackbot> Date: 18 February 2009

<ChrisL> Meeting: Annual Barbeque Outing

<shepazu> ChrisL, new phone number is 02 9976 8721

<ChrisL> thanks!

<ChrisL> 02?

<shepazu> sorry, +612

<ChrisL> gotcha

<anthony> not 02

<ed__> new room, new countrycode

<ChrisL> was the old troom not to your liking? insufficient sea views, perhaps?

<shepazu> the new room is *much* further away

<heycam> Scribe: Cameron

<heycam> ScribeNick: heycam

SVG 3D transforms

ED: anthony you were saying it's mostly done, ready for publication?

AG: the changes we talked about on tuesday i've started folding in
... i was going to add a bit more wording on how to handle the order of rendering and maybe put in the backface-visibility

CM: don't think we agreed to backface-visibilty yet

ED: don't need to put everything in yet

AG: the other thing is layeredGroup
... that can probably wait as well, can put in a comment that mention backface-visibility and layeredGroup as possible things to be added later

<ChrisL> Dean's comments on Steve Zilles' objection http://lists.w3.org/Archives/Member/w3c-css-wg/2009JanMar/0104.html

DS: also put in the spec that we're seeking to converge with CSS on a single solution

AG: need to update the use cases document with a few points we made the other day
... openvg requirement
... and the general plan to have alignment between our's and CSS'

DS: they don't have a use cases and requirements document

AG: i've put together all my thoughts from tuesday and i'll draft up an email to send it to our list for review

DS: so it seems like you took a lot of stuff from theirs

AG: yes
... we had an earlier proposal but we wanted to align more closely with theirs
... so that implementors and users could have consistent functionality

CM: you'll have that draft mail ready for when?

AG: could be today

DS: any objections to publishing svg 3d transforms?

JW: no objections, but haven't got a good understanding of the module yet

<ChrisL> We need to be sure that the CSS transform stuff fits with SVG transforms, when both are applied. Dean mentioned this in his email

RESOLUTION: We'll publish what we have currently for the SVG 3D Transforms module

<scribe> ACTION: Anthony to prepare SVG 3D Transforms for publication [recorded in http://www.w3.org/2009/02/18-svg-minutes.html#action01]

<trackbot> Created ACTION-2474 - Prepare SVG 3D Transforms for publication [on Anthony Grasso - due 2009-02-25].

<scribe> ACTION: Doug to prepare SVG 3D Transforms for publication [recorded in http://www.w3.org/2009/02/18-svg-minutes.html#action02]

<trackbot> Created ACTION-2475 - Prepare SVG 3D Transforms for publication [on Doug Schepers - due 2009-02-25].

Vector effects

<ChrisL> http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffectsPrimer.html

<ChrisL> http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffects.html

ED: starting with the primer

CL: i've started to explain in general terms about rendering order and combining stuff, how to make compound shapes
... there's a useful diagram with text-with-stroke
... where it looks ugly with the stroking on top, and nice with stroking behind
... then i summarise what vector effects can do
... the basic idea is that in 1.1 and 1.2T, the default rendering order is fill then stroke then markers
... always in that order, and exactly one stroke, etc.
... the idea is to have a property on any shape that lets you modify that
... so you can stroke/fill in different orders, multiple strokes, modify the shape of the stroke, convert the stroke to a path and then stroke it, etc.
... one particular use case, which came from andreas neumann, for cartography is to have pieces of geometry and stitch them together
... e.g. the border between france and belgium, you want to just render that border once
... then i go through in the same order as the language spec giving a one or two sentence explanation of each primitive and a picture
... so the first one is veStrokePath
... i put a thick stroke on it and turn it into a path and then stroke it

DS: chris did you change the image for the previous example?

CL: yes i've done a bit of tidying up

JW: when you say the stroke is converted to a path, you mean the edges of the stroke become a path and then those edges are stroked themselves

CL: right
... veStroke is a command to draw a stroke, but you can have multiple ones of them
... in the example there are three of them
... veReverse changes the orientation of a path
... probably only useful in combination with something else, e.g. markers
... any markers that are asymmetric and oriented automatically are flipped

ED: this could be useful for motion path as well?

CL: yes it could

DS: this would have effects on fill

CL: yes it would

DS: fill-rule="evenOdd"

CL: next one is veUnion
... merges two shapes together
... two drawings for that, two random shapes unioned
... the other example is having a thick stroke, converted that to a stroke, then unioned them
... so that's like an outset effect

DS: is that unioning the colours too?

CL: no it's just the shape

CM: do you think it's worth having an explicit veOffset primitive?

CL: maybe
... i wonder whether inset/outset should be added
... next is veIntersect, which does intersection
... subtraction of shapes
... hopefully that example makes it obvious what veIntersect is useful for

DS: would the fill-rule properties have an effect here too?

CL: yes they would

DS: one thing with fill-rule i've wanted is a third value that can fill all the interior of shapes

CL: if they were separate shapes you could do that with a union

DS: so basically take the outline, and fill everything inside (and still have strokes etc.)

CL: next one down is a veExclude
... you can do an "inside stroke" effect with it, i'll add an example for it
... next are examples that are originally from peter sorotokin
... let's move on to the language spec

DS: when reading in the language spec it talks about the default rendering order, i'd put a visual example of what is meant by that

<ChrisL> http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffects.html

CL: this is much more littered with ednotes
... first is the vectorEffect element
... you can use it like you use a filter
... putting it in a <defs>
... but also you can use it as a drawing primitive directly
... so if you do want to hide it you need to put it into <defs>
... it should be possible to do both

ED: you could put display:none on it and reference it from somewhere else

CL: there's a couple of attribute definitions
... 'clipout', which doesn't have any examples
... i need to look at that a bit more
... most of this has been taken from the original 1.2 chapter
... i've tried to tidy it up
... as doug says, the default vector effect is there in this section

AG: i'll send in some comments about wording

CL: so this is an advantage compared to filter primitives, we say what happens when you have a "null" one
... which is that there's no rendering
... next section, there's a big ednote
... so not all of these attributes are available on *all* vector effect primtiives
... so i will redo this section
... the definitions of these common attributes need to be here, but they're not all used on all primitives
... i was looking in the filters chapter, there was the same kind of thing, e.g. x/y/width/height are used on lots of primtiives
... i'll do that same editing here

DS: it might help people conceptualize this if you point out that the way this works is a bit like filters
... it's like a graph of primitives
... and it's similar in its syntax and way of defining effects

ED: some of the vector effects will be more expensive than others

DS: it'd be good to point out which ones are more expensive than others (for both vector effects and filter effects)

ED: there is some wording like that in the filters spec, but it's not really on everything
... would you like to see two classes of conforming UAs?

CL: i think it's more guidance for authors

DS: yes

CL: e.g. telling them that they shouldn't set the filter region to the whole canvas
... the other ednote in this section is whether the attributes are animatable or not
... some of them i made guesses, since it didn't say so in the 1.2 draft

CM: in the filters spec are in and in2 animatable?

ED: yes

<ChrisL> so they should be animatable here also

ED: result is also animatable in the filters spec

CM: what's the diff between transform and transformPath?

CL: it's not immediately clear
... one of them, transform, it basically pops you into a different coordiante space, does the operation, and then reverses the transformation
... whereas transformPath, oddly named, just does a transform
... so if you go up to the primer again, and look at the second diagram, with three hearts
... the pink heart with the skewed blue stroke, that would be an example of transformPath
... we can rename these two attributes
... the idea is that most of the outputs of these primitives are paths
... so all it's done is transform it
... if you transformed it into something that's three times as wide, it would end up being thin
... if transform it, stroke, then inverse transform it, the stroke ends up not being uniformly thick
... next is veStrokePath
... it takes the stroke and turns it into a path, basically
... if you don't give it any params, it takes what the stroke would've been
... but you can provide attributes on the element to give it different stroking
... there are the usual things you can put on strokes, e.g. stroke-dasharray, stroke-width, et.c
... in the original spec, these were defined with a bit of RNG
... so far these are all the same as the correspondingly named property
... do we need to allow the word inherit?
... where you'd inherit from, the parent, wouldn't have useful values

CM: so these are attributes and not properties?

CL: if they're properties, then you can style them
... but the disadvantage is that you'd have properties with same names but different sets of values
... then you'd need to rename them to something else
... the value of using a stylesheet isn't that high, imo

ED: if you use the same attribute names, it could be a bit tricky with parsing and mapping them to properties
... maybe we should rename the attributes?

CL: we could prefix them all with "ve" e.g.

CM: they're like the font attributes

CL: it puts a bit of work on the implementor, but i think it makes it more understandable for the author
... as it is now, they're the same (except for perhaps removing "inherit")
... stroke-opacity was missing from the original spec, so i've added it here

ED: so veStrokePath produces an outline, how would opacity affect the outline?

CL: all of these attributes are controlling the stroke, then you're converting that to a path
... there's a veStroke as well, which has all the same attributes on it
... the properties are the ones pertaining to the stroke
... e.g. if you had stroke-dasharray, each dash gets converted to a subpath

ED: if you have stroke-opacity:0.5, what effect would it have?

CL: it'd be the same as setting stroke-opacity:0.5 normally

ED: so it has no effect on the path, just how it's rendering?

CL: next is veSetback
... it has a single attribute, a list of four lengths
... i need to draw a diagram for this
... imagine an arc with arrowheads
... then you put a really thick stroke on the line
... so parts of the line stroke come out past the arrowhead
... so it puts it sets the path back

DS: so that's similar to the offset on paths

JW: why can't you set the origin of the maker to match the end of the stroke?

DS: they have to give numeric values, they can't say "put it at the end of the stroke"
... they have to judge themselves what the right offset is

[doug draws]

JW: with setback you need to keep a track of the marker dimensions
... perhaps easier is to say that the stroke is masked out by the marker, haven't thought that through though

CL: so you'd convert the stroke to a path, and convert the marker to a path, then use the union/exclusion operations

CM: there should be some simple thing to say "automatically draw the path up to the right point of the back of the marker"
... maybe markers should have two origin points (the front and the back of the arrowhead)

DS: i'd suggest marking veSetback as needing examination for use cases

CL: veAffine is next
... it just moves the path, applies a transform to the path
... veReverse, the diagram in the primer explains that
... next, veJoin, don't have an example of that
... it takes two paths and concatenates them
... with an attribute that says whether to insert a lineto to join them

ED: with veAffine, would that apply 3d transforms?

CL: maybe veTransform would a better name than veAffine then

CM: maybe a third option for 'connect' to make the start point of the second path be the same as the end point of the first path
... not sure of the use cases though

CL: next three

CM: the algorithms for some of these things might not be well known

CL: inkscape implements them, mostly
... i'm wondering if these child elements should be in alphabetical order
... veFill is how you do your basic fill
... it has the usual fill properties
... in theory you could do multiple fills
... the examples use these values "currentStrokeOpacity" etc., but they're not valid values yet
... particularly useful here would be to allow markers to be painted with whatever the current stroke paint is

DS: if you have a marker with stroke green fill lime, and i want to change it to cornflowerblue/blue

CL: you want to do computations on the colour values?

DS: not necessarily
... we could say that in the marker, give it keyword values
... i often have different colours for the fill and the stroke

CM: is there a marker-opacity?

ED: no, but you can put opacity on the contents of the marker itself

ISSUE: We need to define the order of rendering for markers on a path

<trackbot> Created ISSUE-2229 - We need to define the order of rendering for markers on a path ; please complete additional details at http://www.w3.org/Graphics/SVG/WG/track/issues/2229/edit .

CM: there's a question there, is fill-rule needed on veFill?
... might be good to just include them all

CL: a question for marker
... there is a marker shorthand
... when we made attribute questions, we decided not to have attributes for shorthands
... because attributes are unordered
... if you said marker="blah" marker-start="foo" you wouldn't know which one wins
... otoh people often do says marker:blah and put the same marker on everything

ED: in our implementation, you wouldn't look at the values until you need the cascaded values
... so it shouldn't be a problem

CL: otherwise currently you have to repeat those three marker-* attributes
... however some implementations allow you to do that
... those implementations are inconsistent on which ones win

CM: same for @font i guess

ED: they're the only shorthands we have, i think

CL: veMarkerPath, this lets you convert a marker to the union of marker contents

CM: what happens to the styling of the shapes within the marker?

CL: the output is a path
... most of these elements produce another path, some of them draw something
... you'd need to use them in combination, often
... vePath and vePathRef are interesting
... vePath is a parent, with any number of vePathRef children
... this is how you take 20 different paths and combine them all
... in some cases you need to reverse them as well

CM: so you would define boundary paths, them reference them here

DS: as an aside, in firefox if you set stroke-opacity it doesn't do anything do the marker
... setting fill-opacity doesn't do anything
... setting opacity it does

CL: next is the vector-effect property
... we've already used part of this in 1.2T, the non-scaling-stroke thing

CM: would you imagine introducing new keywords for more canned vector effects?

CL: so you can also specify "default", which is the plain vector effect

ED: in tiny the initial value is "none", rather than "default"

<ed__> http://www.w3.org/TR/SVGMobile12/painting.html#NonScalingStroke

CL: so we'll keep the value "none" and explain it means the default vector effect
... next issue is that we have the default vector effect; what happens in 1.2T that doesn't implement markers?
... can you use veMarker when you don't support markers?
... is it a no-op

CM: is it likely that there will be implementations that do full vector effects but not markers?

CL: probably

CM: easiest would be to say that veMarker is a no-op, imo

CL: we could have language in there that says "if the host language supports marker, then..."
... note here the definition of non-scaling-stroke

ED: ref(host) should be ref(svg)

CL: back to the examples in the primer
... the second example is a fill pattern that doesn't scale
... the third example is bogus, stroke-width-adjust doesn't appear anywhere else in the spec

ED: if you use stroke-width="nn%"
... then just say that percentages there are resolved against the stroke-width on the original path

CM: i guess that's similar to font-size percentage resolution

CL: next is the example that was at the top of the document
... next is the example making markers take the colour of the stroke

DS: this satisfies a longstanding problem with markers
... could you change the opacity of the marker, or stroke-dasharray of the marker?

CL: markers can be arbitrarily complex
... and markers can have markers
... there's an example in the test suite where markers have markers
... two more examples, one is the same as the preceding but a bit different
... converts the fill/stroke/marker to a single path, and then paints it
... you can see the example of this when using a gradient, e.g.
... the last example shows vePath

ED: it'd be good to see an example of a map, to see if it's actually more compact
... there's a lot of syntax with the vePath stuff

CL: with a large number of points in the paths, it'd be a win
... the other thing here is that if you export the same thing multiple times, especially with paths reversed, you can sometimes get paths that don't fit together exactly

<ChrisL> what was the nuber again?

+61 2 9976 8721

<ChrisL> i got a receptionist

ok let me check

hmm

try again? the number should be right

CM: what would happen with events?

CL: you should be able to put event handles on these things that are drawn
... same with symbol/use, what happens there?

ED: there's the SVGElementInstance tree objects

JW: why are we using xlink:href on these?

CL: because that's what we use everywhere

JW: how about dropping the xlink prefix here?

CL: if you want to suggest dropping xlink prefix everywhere, that'd be more reasonable
... but not just on the one

DS: for text, i think we should special case it to say that the stroke is by default behind the fill

CM: have a canned stroke-behind vector effect?

<ChrisL> someone mentioned putting ve ona group?

CM: so you could put vector-effect property on a group

CL: not sure that's supported currently

DS: we might like to say that the stroke is behind all of the text glyphs

"Each property may also have a specified value of 'inherit', which means that, for a given element, the property takes the same computed value as the property for the element's parent."

DS: it'd be useful to have an interface to get resulting path geometry from vector effects
... i couldn't figure out how to do variable stroke width

CL: i don't think you could with this, it might be possible to add it

DS: could be that we do it with some other mechanism than vector effects

CM: just add a new stroke property

<shepazu> http://www.inkscape.org/screenshots/gallery/inkscape-0.45-patternalongpath.png

CL: you could have something like a gradient definition
... to define the varying stroke width

CM: might be simpler to just have lists of numbers in properties

CL: the face one could be done with that gradient-like definition
... the snake one looks complex

CM: a brush element that can be referenced?

DS: there was an example of someone using an SVG font to make custom shapes, and then place the shapes along a path (with textPath)

<ChrisL> object-on-a-path

CM: when will we publish this?

CL: i'd like to get these comments discussed today addressed

ED: it'd be nice to have some thought go in to the DOM aspects of this
... there's nothing so far, but maybe there should be something

CSS transitions

<ed__> http://dev.w3.org/csswg/css3-transitions

ED: i didn't find what happens when there's a mismatch between the number of transition-property and transition-duration properties

Back to vector effects for a minute

DS: alex adam asked what's the use case for union, intersect and include
... he says, isn't that something that an authoring tool should do?
... to me, the use case is that these things might change dynamically, they might be animated
... or you're just constructing paths at run time
... to me, that's the use case, but we should talk about the explicitly, and talk with the inkscape community to see if this is something that they want

CL: i'd like to have a draft out before libre graphics, and talk to those guys there

JW: it's a fair question, anyway

ED: perhaps different conformance classes, maybe for authoring tools

AG: the vector-effects property doesn't mention styling, but it has visual effects, should it go in CSS?

ED: it's a css property

AG: ok

CSS transitions

ED: so i couldn't find what happens when there is a mismatch
... there's a table at the end that says animatable properties
... why define in that spec which properties are animatable?

CM: maybe as an initial definition of which ones are animatable

ED: it misses out some SVG properties
... also he leaves out a bunch of the ones that are keyword values

CM: in SVG all properties are animatable

ED: in 1.2T we have two properties that aren't animatable
... for the svg properties, it should just point to the svg spec to determine whether it is animatable

DS: maybe they just want a single place to list which properties are animatable, but maybe a tutorial is better for that

ED: for the css props that svg imports, i haven't checked the table to see if there are any mismatches in animatability
... this spec is quite simple, so my question would be is it useful to have this spec if css animations is also there?
... what's the point of making this spec simple if it doesn't address the use cases that css animations does?

DS: iirc, the transitions were meant to be really simple
... there was some disagreement, that bert saw the use cases for transitions but not for animations (iirc)

ED: i would prefer that transitions becomes as simple as possible
... i'm a bit worried about the animation of svg properties, and if the animation here will be different from the interpolation we use here and in smil
... it's not that well defined what happens
... you could say that it's overly complex to have cubic-bezier(), because it does specify a bunch of canned timing functions already
... are those canned ones the ones that cover most use cases?
... i suspect most people will use the canned ones

CM: how is the effect applied? override style sheet? or somewhere in the computation of computed value?

JW: i think it's basically the override style sheet
... there is a property you can specify on elements to disable animation
... that's in css animations
... not clear on that

CM: animations doesn't really build on top of transitions

DS: it builds on the idea, but not the syntax or behaviour

ED: does it define "<time>" as the value of transition-delay?
... it doesn't link to where that grammar is defined
... in CSS 2.1, there was one for aural style sheets
... which allows you to specify a time with either "s" or "ms" suffixes
... so it would be a bit different from the clock values used in SVG/SMIL
... not sure if that's the correct definition intended, though
... it should be linked to the correct place
... the same applies for all the ones that can specify multiple values
... what happens if the number of animated transition properties is not the same as the number of transition-delays, etc.
... also not sure why it says why it says it applies to block-level and inline-level elements. so it doesn't work on svg elements?
... why not just say any elements?
... if you have 20 properties that you want to animate, you'd need to put them one after another in the properties
... and have a long string of numbers in transition-duration, e.g.
... it does make it more compact, but it's also hard to read

CM: also you really want to add new transitions rather than replace those properties, if you have multiple style rules that match an element and which specify transitions
... so how does this work in combination with SVG animations?

ED: in svg you have an override style sheet for the animated properties
... which would win?

CM: they should define exactly how transitions are applied

ED: if transitions start before svg animations start, you might get a different underlying value for svg animations

JW: they say you take a snapshot of the underlying values
... they don't define what happens if you've got the delay, when that snapshot happens
... after or before the delay?

CM: CSS Transitions doesn't mention anything about snapshots

DS: it should say what happens with script changing values
... though it says that animations builds on transitions, it doesn't say what happens when they conflict
... i've thought it would be useful to say that the property being animated in smil affects the dom

ED: you could use getPresentationBlah()

DS: sometimes you might want to change the actual Attr node values

CM: how are transitions triggered?
... it's not clearly defined

JW: we should split up our comments into things that concern them (e.g. underdefined things) and things which concern us, because of integration with svg animations
... the integration with svg comments should come early

ED: they have TransitionEvents
... in SVG we have TimeEvents, from SMIL
... why not use those instead of introducing new ones?

CM: they have propertyName and elapsedTime properties on TransitionEvent interface

ED: on TimeEvent we only use detail, which is the repeat count

CM: these get dispatched to the target of the transition/animation, and ours are dispatched to the animation element

ED: when are the transition events raised? if you had one that was very short, so it does begin, and the duration is very short, so you never paint the end value
... is it possible to not have the end event in some situations like that?

CM: there's no begin

ED: ok that doesn't matter then
... still you might have a transition that lasts very short, would you still get the event

CM: they have "Context Info: propertyName ", shouldn't that include elapsedTime too?
... what's the purpose of having a transition on properties like 'visibility'?

JW: you get the delay

CM: but apart from that it seems useless
... it doesn't define how interpolation of gradients work
... I don't think you can interpolate gradients from transitions in SVG
... since the values are url()
... i *guess* you could generate data URLs containing <linearGradient> with appropriate <stop> values inside? but that doesn't sounds like what they mean
... why is interpolation of scaleZ defined in the css 2d animations spec?
... they can interpolate matrix transforms by decomposing them first and then interpolating the decomposed transform items
... but we don't have animateTransform type="matrix"

http://dev.w3.org/csswg/css3-2d-transforms/#animation

JW: for the animation of colour, it says to take each rgb component and animate them individually
... but that's not always useful

CM: svg has color-interpolation to control this

JW: if you're going to break things up into components, and someone specifies an hsl() colour it shouldn't be interpolated in rgb space

ED: also you might have percentages in one and integers in another

CSS Animations

<ed__> http://dev.w3.org/csswg/css3-animations

<jwatt> scribenick: jwatt

CM: it says "In the case of multiple animations specifying behavior for the same property, the animation defined last will override the previously defined animations."
... that's different from SMIL Animation which says that the most recently begun animation takes priority
... [tests]

<ed__> JW: what if all of them are begun at the same time?

<ed__> CM: then it's document order IIRC

JW: isn't this referring to the order of the names specified in the ‘animation-name’ property?

<heycam> http://mcc.id.au/temp/2009/animorder.svg

CM: that's probably what it means, that makes more sense

JW: or hopefully that's what it means
... the order of keyframe at rules shouldn't matter I think

CM: it does say the animation "defined last" which sounds more like the at rule declaration order though

JW: so what would the CSS spec have to say to be more compatible?

CM: the animation that most recently began applying would be the one that started last
... the document order doesn't really matter I guess
... they talk about the "intrinsic style"

ED: they need to define the term

CM: it's not clear whether the 'animation-timing' properties are used in the @rule or outside

<ed__> ED: same as for css-transitions the "applies to: block and inlinelevel elements" should probably be just elements, unless there's a good reason for disallowing svg elements to have animations on its properties

JW: I think the ‘animation-name’ property is the only one that doesn't go in an @rule

CM: the animation shorthand property allows you to combine ‘animation-name’ and others though

<ed__> [[Properties that are unable to be animated are ignored in these rules, with the exception of animation-timing-function', the behavior of which is described below.]]

ED: it doesn't say who decides whether something cannot be animated...spec? which? which? implementation? ...?
... the grammar for the keyframes doesn't define whitespace

DS: they're generally pretty good with their syntax, but yes, that needs defined

CM: another thing about grammar
... the grammar says ident, but the examples use strings with quotes around them
... not sure why it restricts to visual media - might have aural properties where it would be useful
... the events are defined to be cancellable, but it doesn't say what it means to cancel them
... the definitions of the constants - someone has claimed 7 already?

<heycam> const unsigned short COLOR_PROFILE_RULE = 7

CM: yes, SVG does

<heycam> that's on SVGCSSRule in SVG (so technically not on CSSRule)

CM: that's been there since 1.0 (since 2001)
... but I bet the SVG WG at the time may well have not have told the CSS group
... so to potential SMIL Animation - CSS Animation integration problems
... if CSS animations are meant to be done using the override stylesheets, then since that's how it works in SVG, how will the final value be resolved?
... I think that's the main one

JW: should we adopt the ‘animation-timing-function’ property keywords

DS: sounds like a good idea

CM: keysplines="ease"

JW: yeah

DS: we should put together our individual reviews and send them in
... we want to coordinate with them so that we have compatible syntax

ED: it would be good to see their use cases and requirements document
... I'd be curious to see a list of use cases that it meets that isn't met by SMIL Timesheets

Filters

<heycam> Scribe: Cameron

<heycam> ScribeNick: heycam

ED: ISSUE-2181

ISSUE-2181?

<trackbot> ISSUE-2181 -- Look at Solutions for 'filter' Property Conflict with IE Filters -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2181

JW: so in old versions of IE they'll get unhappy?

ED: the problem is that some scripts do if (elt.style.filter) to sniff for IE

CM: some browsers make the svgElement.style.filter value "falseish"

ED: opera doesn't

<ed__> (yet anyway)

ED: it seems that maciej was favouring changing the name of the accessor
... so e.g. svgElement.style.svgFilter

JW: i don't think the spec should acknowledge the problem, just ignore it
... you could put an informative note

ED: there's no css spec that say the CSS properties that SVG adds are on CSS2Properties (or whatever the relevant interface)

<ed__> http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-CSS2Properties

http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-CSS2Properties

dashed property names map to camel case attribute names there

<ed__> JW: i think browsers can handle this case, and be smart about detecting it "looking for IE"

<ed__> ...no need for dirty hack like changing the name to e.g svgFilter

<ed__> ...but i'm fine with adding an informative note in the cssom spec about this

<scribe> ACTION: Erik to talk to Anne about handling SVG properties in CSS OM, and adding the informative note about 'filter' [recorded in http://www.w3.org/2009/02/18-svg-minutes.html#action03]

<trackbot> Created ACTION-2476 - Talk to Anne about handling SVG properties in CSS OM, and adding the informative note about 'filter' [on Erik Dahlström - due 2009-02-26].

ISSUE-2071?

<trackbot> ISSUE-2071 -- potential security hole involving pointer-events, filters, foreignObject, cross-origin IFRAMEs, and elementFromPoint -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2071

CM: I think we need to think about pointer-events with non-shapes and non-<image> elements and define that better

https: //developer.mozilla.org/en/DOM/document.elementFromPoint

<ed__> ACTION: DS to Propose a solution for ISSUE-2071, referring to external resources and how that affects security ("tainting" an svg) and how that might apply to methods like elementFromPoint [recorded in http://www.w3.org/2009/02/18-svg-minutes.html#action04]

<trackbot> Created ACTION-2477 - Propose a solution for ISSUE-2071, referring to external resources and how that affects security (\"tainting\" an svg) and how that might apply to methods like elementFromPoint [on Doug Schepers - due 2009-02-26].

[various unminuted discussion]

ED: naming convention for module test cases
... i don't know what to call them

CM: don't want to conflict with SVG 1.1 test case names

AG: I think just put "-m" suffix on each test
... ("m" for module)

DS: i say "filters-<conformancestatementid>-<fourdigitnumber>.svg"

JW: can we use something other than CVS for the tests?

Layout

http://dev.w3.org/SVG/modules/layout/publish/SVGLayoutReqs.html

<ed__> ED: I'd like some generic way of saying "50%+10px" or similar, for attributes that currently take e.g length values

<ed__> ... and also some way of defining what those percentages are relative to

<ed__> ... it would then be possible to remove the filterMarginUnits and mx,my etc attributes in the filters module

<ed__> DS: [talks about params-proposal]

<ed__> CM: arbitrary arithmetic in attributes?

<ed__> DS: maybe verbose, but may let people solve problems

<ed__> CM: would like to see canned ones

<ed__> DS: it would be useful i think

<ed__> CM: would you only like addition or other operations also?

<ed__> ED: might be others that could be useful as well

<ed__> DS: [lays out a tree structure using menthos wrappers]

<ed__> ...[talks about positional relationships and semantics]

<ed__> CM: paddings and margins are things we should support yes

<ed__> DS: would like for the a way of expressing semantics for the content

<ed__> CM: right, but inferring it from the expressions/layout might not be the right way, perhaps aria though

<ed__> ...i don't think it'd be a requirement that an expressionbased layout would infer semantics

<ed__> CM: ok, first one: <length> + <length>

<ed__> JW: right, so 20em + 1px (or minus)

<ed__> CM: next is arbitrary arithmetic expressions of lengths

<ed__> ...is that useful?

<ed__> ...you could do multiplications with additions

<ed__> JW: would like to see use-cases for that

<ed__> ED: we might consider having functions, sin, cos etc...

<ed__> CM: next level, being able to refer to the lenght of a different element

<ed__> JW: i don't think that's a level continuing from the others, but a new category

<ed__> CM: cycles are a problem in such a model

<ed__> JW: tracking values is a larger engineering problem

<ed__> CM: well, svg already has alot of things that needs to be tracked, for updates etc

<ed__> DS: if this layout scheme became popular then it might get used outside of svg

<ed__> JW: say I change a length that depends on a lenght, that depends on a length

<ed__> ...not trivial

<ed__> CM: not terribly complex

<ed__> JW: you'd need to keep a table of dependencies, concerned that it might not be efficient

<ed__> CM: having one-way assignment of lengths depending on other lengths is good for simple cases, but not for more complex ones

<ed__> DS: right, for things like the available screenspace for example

<ed__> CM: [draws on whiteboard]

<ed__> ...doing gridbag layout isn't very convinient with this style of writing the constraints

<ed__> ...we'd like probably to have some form of containers for constraining the layout

<ed__> JW: so why couldn't CSS do this?

<ed__> ED: because it's only concerned with the box model?

<ed__> JW: right, perhaps it should look outside that

<ed__> ...if we define our tags then do we expect people to use those to do layout? (outside of svg)

<ed__> DS: doesn't always apply, some things can't be done that way... different layout, let's not jump to conclusions yet

<ed__> JW: i'd not like to see every spec define its own custom markup for layout

<ed__> ...but let's work out the requirements first

<ed__> DS: [draws a springs and struts layout system]

<ed__> ...it's a simple model

<ed__> CM: if a spring spans across a parent-child boundary then it becomes difficult to solve

<ed__> AG: in that particular model, find me the optimal layout of this

<ed__> ...and you want to fit that to some region

<ed__> CM: that's probably a step up, that's harder to solve

<ed__> ...[long discussion on collision detection and layout]

<shepazu> [discussion about springs-and-struts and other models]

<shepazu> I propose an "intersection" event

<shepazu> ... which would give the objects that intersected, and their vectors

<jwatt> JW: I think in the general case getting precise vectors would be hard

<jwatt> ... not sure how easily an acceptable approximation could be obtained

<jwatt> ... in the general case

<jwatt> ... and you want to be able to get the outline of the group to get the boundary

<jwatt> ... the union of all descendants

<jwatt> ... which if you're doing collision detection over a large number of objects with many descendant graphic elements - every animation sample - you'd think it would hurt

<ed__> CM: so we're agreed that R3 Support fallback to non-layout capable user agents should be reworded to add "where worthwhile"

<ed__> ...R4

<ed__> ...so people often find fonts are different in different viewers, and you want to adapt to it

<ed__> JW: should mention language there

<ed__> CM: next R5

<ed__> JW: might want some examples with R6 for the color depth and its effects on layout

<ed__> CM: might make R7 a bit more generic, to cover more cases

<ed__> JW: on a barchart scaling the bars buit not the gaps would require layout of some sort

- DRAFT -

SVG Working Group Teleconference

18 Feb 2009

Attendees

Contents

SVG 3D transforms

Vector effects

CSS transitions

Back to vector effects for a minute

CSS transitions

CSS Animations

Filters

Layout

Summary of Action Items

Scribe.perl diagnostic output