- From: Cameron McCormack <cam@mcc.id.au>
- Date: Thu, 19 Feb 2009 21:57:13 +1100
- To: public-svg-wg@w3.org
http://www.w3.org/2009/02/18-svg-minutes.html
[1]W3C
[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
Attendees
Present
Regrets
Chair
wooden item for sitting upon
Scribe
Cameron
Contents
* [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.h
tml
[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
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
[14]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
[15]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>
[16]http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffe
ctsPrimer.html
[16] http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffectsPrimer.html
<ChrisL>
[17]http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffe
cts.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
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>
[18]http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffe
cts.html
[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
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 [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
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__>
[20]http://www.w3.org/TR/SVGMobile12/painting.html#NonScalingStroke
[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
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>
[21]http://www.inkscape.org/screenshots/gallery/inkscape-0.45-patter
nalongpath.png
[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
this
... 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
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"
[23]http://dev.w3.org/csswg/css3-2d-transforms/#animation
[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
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> [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
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__>
[27]http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-CSS2Properti
es
[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-CSS2Properti
es
[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
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 [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].
ISSUE-2071?
<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?
Layout
[32]http://dev.w3.org/SVG/modules/layout/publish/SVGLayoutReqs.html
[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
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
Summary of Action Items
[NEW] ACTION: Anthony to prepare SVG 3D Transforms for publication
[recorded in
[33]http://www.w3.org/2009/02/18-svg-minutes.html#action01]
[NEW] ACTION: Doug to prepare SVG 3D Transforms for publication
[recorded in
[34]http://www.w3.org/2009/02/18-svg-minutes.html#action02]
[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
[36]http://www.w3.org/2009/02/18-svg-minutes.html#action03]
[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
/scribe/
[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