W3C home > Mailing lists > Public > public-svg-wg@w3.org > January to March 2009

Minutes Sydney 2009 F2F day 4

From: Cameron McCormack <cam@mcc.id.au>
Date: Thu, 19 Feb 2009 21:57:13 +1100
To: public-svg-wg@w3.org
Message-ID: <20090219105713.GB27320@arc.mcc.id.au>


      [1] http://www.w3.org/

                               - DRAFT -

                   SVG Working Group Teleconference

18 Feb 2009

   See also: [2]IRC log

      [2] http://www.w3.org/2009/02/18-svg-irc


          wooden item for sitting upon



     * [3]Topics
         1. [4]SVG 3D transforms
         2. [5]Vector effects
         3. [6]CSS transitions
         4. [7]Back to vector effects for a minute
         5. [8]CSS transitions
         6. [9]CSS Animations
         7. [10]Filters
         8. [11]Layout
     * [12]Summary of Action Items

   <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

     [13] 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

   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

   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

   <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

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

Vector effects


     [16] http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffectsPrimer.html


     [17] 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
   ... 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

   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.
   ... any markers that are asymmetric and oriented automatically are

   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


     [18] 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

   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

   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
   ... 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
   ... 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
   ... do we need to allow the word inherit?
   ... where you'd inherit from, the parent, wouldn't have useful

   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
   ... 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
   ... the properties are the ones pertaining to the stroke
   ... e.g. if you had stroke-dasharray, each dash gets converted to a

   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

   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

   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
   ... 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

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

     [19] 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

   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-*
   ... 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
   ... 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

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

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

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


     [20] 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
   ... 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


   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
   ... 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

   "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

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

   CM: just add a new stroke property


     [21] 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
   ... there's nothing so far, but maybe there should be something

CSS transitions

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

     [22] 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
   ... 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
   ... 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"
   ... so it would be a bit different from the clock values used in
   ... 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
   ... 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
   ... 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

   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

   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
   ... 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
   ... they can interpolate matrix transforms by decomposing them first
   and then interpolating the decomposed transform items
   ... but we don't have animateTransform type="matrix"


     [23] 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__> [24]http://dev.w3.org/csswg/css3-animations

     [24] 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> [25]http://mcc.id.au/temp/2009/animorder.svg

     [25] 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

   <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
   ... 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

   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

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


   <heycam> Scribe: Cameron

   <heycam> ScribeNick: heycam

   ED: ISSUE-2181


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

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

     [26] 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
   ... 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)


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


     [28] 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

   <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 [29]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].


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

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

     [30] 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 [31]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?



     [32] 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

   <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

   <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

   <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

   <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

Summary of Action Items

   [NEW] ACTION: Anthony to prepare SVG 3D Transforms for publication
   [recorded in
   [NEW] ACTION: Doug to prepare SVG 3D Transforms for publication
   [recorded in
   [NEW] 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 [35]http://www.w3.org/2009/02/18-svg-minutes.html#action04]
   [NEW] ACTION: Erik to talk to Anne about handling SVG properties in
   CSS OM, and adding the informative note about 'filter' [recorded in

   [End of minutes]

    Minutes formatted by David Booth's [37]scribe.perl version 1.133
    ([38]CVS log)
    $Date: 2009/02/19 10:53:46 $

     [37] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [38] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

   [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51
Check for newer version at [39]http://dev.w3.org/cvsweb/~checkout~/2002

     [39] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/yte/yet/
Succeeded: s/CL/CM/
Succeeded: s/subpaths/a subpath/
Succeeded: s/it //
Succeeded: s/strke/stroke/
Succeeded: s/htis/this/
Succeeded: s/object/interface/
Succeeded: s/spec/spec? which/
Succeeded: s/spec/spec? which/
Succeeded: s/oral/aural/
Succeeded: s/Animation/Timesheets/
Succeeded: s/CSSStyleDeclaration/CSS2Properties/
Succeeded: s/specify to//
Succeeded: s/next category/next level/
Found Scribe: Cameron
WARNING: No scribe lines found matching ScribeNick pattern: <Cameron> .
Found ScribeNick: heycam
Found ScribeNick: jwatt
Found Scribe: Cameron
Found ScribeNick: heycam
ScribeNicks: heycam, jwatt

WARNING: No "Present: ... " found!
Possibly Present: AG CL CM ChrisL DS ED ISSUE JW anthony ed__ ed___ hey
cam https joined jwatt left scribenick shepazu svg trackbot
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

Found Date: 18 Feb 2009
Guessing minutes URL: [40]http://www.w3.org/2009/02/18-svg-minutes.html
People with action items: anthony doug ds erik

     [40] http://www.w3.org/2009/02/18-svg-minutes.html

   End of [41]scribe.perl diagnostic output]

     [41] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

Cameron McCormack ≝ http://mcc.id.au/
Received on Thursday, 19 February 2009 10:57:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:29:41 UTC