22:01:00 RRSAgent has joined #svg
22:01:00 logging to http://www.w3.org/2012/01/13-svg-irc
22:01:03 RRSAgent, this meeting spans midnight
22:01:13 Meeting: SVG WG Sydney 2012 F2F day 4
22:01:16 Chair: Erik
22:01:28 stakagi has joined #svg
22:02:24 Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012/Agenda
22:04:24 birtles has joined #svg
22:14:12 ScribeNick: heycam
22:14:14 Topic: Web Animations
22:14:30 http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012/Agenda/Animations/WebAnimations
22:14:59 cyril has joined #svg
22:16:47 BB: the last thing I wanted to put forward was the idea of making this Web Animations spec
22:16:52 … which covers both SVG and CSS animations
22:17:02 … and as was suggested, I think by Dean or someone, also a JS API
22:17:08 … in addition to what we already have
22:17:20 … you can see the basic ideas there [in thel ink]
22:17:47 … there'd be two syntaxes, and along the lines of Filter Effects, it'd probably be that the features available in the CSS syntax would be more limited than those available in the element syntax
22:17:50 … that's the basic idea
22:18:06 … I've written a few very draft ideas, already just talking with Rik I think I've overhauled large parts of those ideas already
22:18:18 … I'll pick out a couple of points
22:18:31 … one would be that animation should be able to target more than one element, SVG Animations are limited in that regard at the moment
22:18:36 … e.g. we might have a select="" attribute
22:18:45 … that's one example of the sort of things I'd add
22:18:45 http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012/Agenda/Animations/WebAnimations
22:19:14 … also you can use an animation defined using an element syntax, reference it using the CSS animation-name property
22:19:32 … also talked with Rik and Vincent about how SVG animations are limited in that they can only target one attribute at a time
22:19:41 … if you want to target more than one, you need another animation
22:19:47 … that's also something we could possibly address here
22:19:58 This is relevant to my interests, and I'd like to be involved in seeing it through. (Shane too, if he's not there today.)
22:20:00 … I have a couple of draft ideas here, maybe a semicolon separated list of attribute names
22:20:13 … that idea of being able to target more than one attribute/property at a time might be useful
22:20:18 … especially with aligning with CSS animations
22:20:33 … one issue that I think I'd like to think about is backwards compat
22:21:00 … I originally was proposing something separate to what we already have in SVG animations, deprecating what we have and replacing it with something that is not backwards compatible
22:21:12 … it's more aligned with CSS animations, but it draws on the learning from SVG's SMIL animation heritage
22:21:15 … that was my initial proposal
22:21:32 … but I think Cameron suggested that he'd like to see if we could keep backwards compatibility
22:21:42 … that's one of the bigger questions
22:21:50 … is it ok to make something new, and deprecate the old
22:22:06 … or is it important to build on what we have, recognise that that might limit how much we can simplify and align with CSS
22:22:11 … maybe that's something we can't answer right now
22:22:15 … we need to do more investgation
22:22:40 … but I'd be keen to hear everyone's views on backwards compatibility and how important is that, how feasible is it to develop new elements
22:22:52 ED: I don't think we can drop current SVG animation support from our implementation
22:23:06 … animateTransform is used, animateColor not so much, animateMotion is useful but not used so much
22:23:14 BB: I'm thinking about deprecating as well
22:23:23 … so this proposal is for something completely separate
22:23:29 … there are subtle differences between CSS and SVG animations
22:23:34 … such as rounding behaviour is different
22:23:46 … if we want to keep our existing syntax, how can we align with CSS and keep backwards compat
22:23:56 … there may be a way to do that, we could have a flag that triggers the different behaviour
22:24:09 … but the alternative would be to come up with new elements
22:24:31 RC: maybe you could define it in such a way, that someone can write a library that implements the new syntax based on the old syntax
22:24:54 BB: the main situation I'm interested in is when you don't have script
22:25:00 … that's when you really need declarative animation
22:25:03 CC: I like some of the ideas
22:25:15 … having one element for the animation, only, that's fine
22:25:24 vhardy has joined #svg
22:25:24 … I like adding selectors, possibilities to target multiple attributes
22:25:33 … but the general idea of redesigning something new, that's the thing I don't like
22:25:39 … I think we could start with the element and augment it
22:25:44 … so it's easier to use
22:25:55 … extend its behaviour so it can do , etc., but not start from scratch
22:25:59 BB: what do you think about naming things?
22:26:04 … one example here is iteration-count
22:26:08 … in SVG it's repeatCOunt
22:26:12 s/repeatCOunt/repeatCount/
22:26:25 CC: it's fine, we can duplicate the attribute if we want to
22:26:53 BB: is it fine to allow also iteration-count and define how it overrides with repeatCount?
22:27:07 ED: the only example similar to this I can think of is xml:id and id, which wasn't too popular
22:27:13 CC: personally I wouldn't mind having different naming
22:27:28 … as long you don't have to store the two different attributes
22:27:33 CM: I think you would have to though
22:27:35 … the DOM would require you to
22:27:52 BB: you could define iteration-count, and if both are used on the element then iteration-count wins
22:28:03 … the syntax might differ too, indefinite vs infinite
22:28:10 RC: why would you not just make the syntax the same?
22:28:52 … and the name?
22:28:58 [iterationCount vs animation-iteration-count]
22:29:41
22:29:49 CM: I don't want to break the identity between presentation attribute names and property names
22:30:19 BB: if we match the names exactly, it forces you to have the same behaviour and parsing
22:30:24 VH: as the CSS properties?
22:30:25 BB: yes
22:30:32 CM: which might be a good thing
22:31:07 If it's desired that we have identical names between CSS and SVG, that pretty much requires matching CSS at this point, given relative usage.
22:31:29 CC: CSS Animations is still a draft, right?
22:31:34 CM: there is content out there
22:31:38 VH: still prefixed though
22:31:44 But I don't think it's a good thing to require "animate" prefix on every attribute of an element. The prefix namespaces the CSS property, but the *element* namespaces the attribute.
22:32:13 TabAtkins, yeah, I think that's Brian's argument. OTOH there are cognitive advantages to using *exactly* the same property names/values as CSS.
22:32:17 CSS is almost certainly *not* able to change its names at this point, unless there's a major problem. "To match an unwritten SVG proposal" isn't a major problem.
22:32:40 TabAtkins, are implementations deployed that use unprefixed names?
22:32:46 (or content?)
22:33:27 No unprefixed impls yet, but there's unprefixed *content* out there that we'd like to match unless there's a good reason not to, plus tons and tons of tutorial and instructional material using the current names.
22:33:28 CC: it's frustrating that CSS animation is not more aligned with SVG animation on simple things like whether floor or round is used for integer interpolation
22:33:39 VH: as a group, we should document these issues, send them to the FX taskforce
22:33:47 … say we feel they should be aligned, request a change to CSS Animation
22:33:58 Cyril: Blame Apple for coming to the WG with a fully-formed and implemented proposal instead of starting discussion early. :/
22:34:06 CC: I can understand they don't want SMIL intervals etc., but in the spirit where you want to round trip between one and the other...
22:34:23 cabanier has joined #svg
22:34:52 VH: Brian could you draft a list of things we ask of CSS Animations to change, like the rounding stuff?
22:35:15 (Details like rounding *are* potentially changeable on the CSS side.)
22:35:16 BB: with what scope?
22:35:28 … it's almost impossble to change names, rounding behaviour there is some hope of changing
22:35:50 VH: the message could just be "here are differences" and a pointer to your document
22:35:59 BB: I think the rounding is the most significant issue
22:36:11 (Names can *often* be changed, but Animations are pretty mature at this point. They should have been CR *long* ago, but the editors stopped working on them.)
22:36:58 CM: we should identify the features that prevent us from extending/aligning while keeping the same name
22:37:28 ACTION: Brian to identify things that prevent us from having align with CSS Animations, and present them as change suggestions for CSS Animations in FXTF
22:37:29 Created ACTION-3223 - Identify things that prevent us from having align with CSS Animations, and present them as change suggestions for CSS Animations in FXTF [on Brian Birtles - due 2012-01-20].
22:39:00 BB: another minor one is indefinite vs infinite
22:39:05 … that's something we could fix on our side
22:39:22 VH: indefinite is used for begin="" as well
22:39:38 BB: that's where I think we should deviate from SMIL
22:40:23 CC: we should encourage authors to use the updated syntax, but existing implementations would still need to support the old stuff
22:40:35 … having a note in the spec for authors about this would be good
22:41:10 BB: the rest I think we talked about yesterday, obviating the need for animateTransform, animateColor
22:41:25 (We have similar cases in CSS where some legacy syntax is explicitly allowed as an alias, but authors have a MUST NOT requirement against using it.
22:41:26 VH: the reason we had for animateColor is that there are properties that take colors and fill patterns
22:42:18 … animateColor indicates that they're just colours
22:42:25 CM: you don't need to indicate that though
22:42:35 … you know you have two colour values, it's clear how to interpolate
22:42:55 CC: for animateMotion, in GPAC the way I implemented it is just using with a pseudo attribute called "motion transform"
22:43:09 BB: that's the direction I'm interested in, partly because if we want to introduce motion animation to CSS animation, it would make it easier
22:43:18 I think that's a good approach.
22:43:19 … CSS Animations doesn't have separate , , etc.
22:43:28 … if we can do it just with , it's easier to bring across to CSS Animations
22:43:50 CC: in the page it says it should also be possible to animate all colour stops of a gradient at the same time?
22:44:24 BB: yes, you can't do that in SVG
22:44:27 CM: but you will be able to
22:44:32 … because we will support css3-image
22:45:26 BB: the main thing I want to get out of this session is some consensus on direction
22:45:30 … and then hammer out details later
22:45:35 … Vincent's already agreed to help me with that
22:45:41 VH: I have a question on
22:46:05 … there was a proposal to have a timing element like , and instead of being an animation element like SMIL, it would actually do a real DOM setAttribute operation
22:46:32 … one difficulty would be what happens if you have two of these, you'd need to define priority
22:46:46 … it could be good for non-scripted situations
22:48:01 … but that's a separate discussion
22:48:41 BB: moving on, I was thinking of adding an element for timing containers, but I don't think that's such a great idea now
22:48:59 … one suggestion was to add a timeContainer attribute on SVG container elements like
22:49:10 … I'll work on that
22:49:20 … but some way of specifying par/seq time containers is what I'd like
22:49:21 http://wam.inrialpes.fr/timesheets/
22:49:57 BB: I would like to work out how to align events
22:50:14 … maybe making TimeEvent a subinterface of AnimationEvent
22:50:31 VH: do any implementations let you use SVG animations target HTML?
22:50:41 BB: yes, Gecko lets you target properties of HTML elements from SVG animation elements
22:51:08 ED: Opera doesn't, but we could
22:51:26 BB: that's another question, whatever we define it should be able to target HTML as well
22:51:33 … and then for HTML, whether targetting properties is enough there
22:51:35 Tab, does WebKit allow you to animate HTML properties with SVG animation elements ?
22:51:44 … and think there's a bit of opposition to targeting HTML attributes
22:52:03 I highly doubt it, but it would be easy to test.
22:52:37 CM: I want to get a sense of whether HTML folks would want this new to be able to be put directly in HTML documents without SVG around it
22:53:15 BB: we can start with just allowing it in SVG, and if it proves useful, see if HTML folks want to allow it directly
22:53:33 … a different discussion perhaps, what to do with DOM storage
22:53:40 … the messy baseVal/animVal
22:53:51 Burn it with fire?
22:53:54 … I wonder what is useful to authors
22:54:08 … I find I just use animVal
22:54:13 ED: I find baseVal more useful
22:54:20 CM: at least when you're modifying you need baseVal
22:54:26 BB: but yes, what do we need out of an SVG DOM APi
22:54:30 I find that I don't use either, and then things break, and then I cuss until I remember and choose one to use semi-randomly.
22:54:56 CM: we will be having a broader discussion about SVG DOM improvments
22:55:12 … I don't think those improvements will impact the rest of your proposals here
22:55:19 s/ find baseVal more useful/ find baseVal more useful because you can read and write to it, unlike with animVal which is readonly/
22:55:48 I suggest we get in touch with Mike Bostock, DmitriB and other animation script lib authors to ask what they want to see in an API
22:56:16 BB: seems like we should move forward with this then
22:56:31 CM: I would like to hear what the non-SVG FXTF people feel though
22:56:48 shepazu, yes good idea
23:14:43 RESOLUTION: We will work on a proposal for a Web Animation spec that underlies SVG and CSS Animations, and write up a summary document on which features ought to be supported in CSS Animations with use cases and examples
23:15:20 ACTION: Brian to work on the Web Animation spec proposal for the May FXTF meeting
23:15:21 Created ACTION-3224 - Work on the Web Animation spec proposal for the May FXTF meeting [on Brian Birtles - due 2012-01-20].
23:16:14 I have made the request to generate http://www.w3.org/2012/01/13-svg-minutes.html shepazu
23:16:28 Topic: moar SVG2 Requirements
23:17:32 (for ChrisL: http://brian.sol1.net/svg/demo/button.svg)
23:17:53 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Look_at_making_paced_animation_easier
23:18:35 RRSAgent, pointer please
23:18:35 See http://www.w3.org/2012/01/13-svg-irc#T23-18-35
23:18:38 ISSUE-2281?
23:18:38 ISSUE-2281 -- Look at making paced animations easier -- raised
23:18:38 http://www.w3.org/Graphics/SVG/WG/track/issues/2281
23:19:35 Doug, do you remember anything on this issue that you raised?
23:19:44 ChrisL has joined #svg
23:19:48 ED: are paced animations hard to write at the moment?
23:19:54 BB: it's mostly just for motion animation at the moment
23:19:57 … not sure what the particular need is here
23:21:16 CM: so this would allow specifying a speed for the motion animation
23:21:29 … since you don't know what dur you would specify
23:21:32 rrsagent, make logs public
23:21:41 zakim,this meeting spans midnight
23:21:44 rrsagent, here
23:21:44 See http://www.w3.org/2012/01/13-svg-irc#T23-21-44
23:21:44 BB: my guess is that cases where you don't know what the path length is, is when you are doing scripted path generation
23:22:20 [[ pace="10px/1s" ]]
23:23:04 BB: and if that's so, you can just do getComputedPathLength [or whatever it is]
23:23:42 DS: yes it's true you could use that method, if you have a
23:23:48 … again that calls for script
23:24:00 … the path might change, then you need to do getComputedPathLength every time
23:24:14 … if the path is moving, and you want the animated object to move at a steady pace it will be more of a pain
23:24:33 … also if you have an animation that is not along a path, you could not do that
23:24:43 … e.g. if you just want to move an object to the right [at a certain speed]
23:25:08 … you could also see this being used when animating colour, if you want an animation to be synced with another of a certain duration
23:25:23 BB: I was thinking when you have that's interesting, because the target path might be changing outside of your control
23:27:16 CM: is it a problem that instance times change because a path length will change, and an animation along the path is specified using a speed?
23:27:27 BB: instance times already can change in the SMIL model, that's one of the more complex parts of SMIL
23:27:39 … maybe it would be bad that instance times get updated every animation tick
23:29:27 … can target an animated path?
23:29:28 ED: yes
23:30:14 CM: probably not the most important feature, but let's accept it (and prioritise later)
23:30:44 BB: this would introduce some coupling between the animation and the timing model
23:30:53 … it's not what you normally do, but if it's useful it might be worth it
23:31:14 RESOLUTION: We will support motion animation of a specified speed in SVG2.
23:31:21 -- break for 15 minutes --
23:47:52 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Basic_SVG_UI_enhancements
23:48:29 ScribeNick: vhardy
23:48:45 ed: SVG UI enhancements
23:49:10 heycam: we discussed this before and decided to not do UI in the zoom/pan features.
23:49:22 ed: this is a bit different.
23:49:30 cl: this is not something we should be adding.
23:50:01 ... it is a huge amount of work and not necessarily what people need.
23:50:39 ... the zoom/pan we talked about and we may add through the 'controls' attribute to switch it on/off.
23:50:57 .. this was rejected earlier.
23:51:18 ... for layers, we already have groups and you can switch on/off layer by toggling visibility.
23:52:39 RESOLUTION: SVG 2.0 will not address the "Basic SVG UI enhancements" requirement.
23:53:17 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Specify_that_unknown_elements_are_treated_as_.3Cg.3E_elements_for_the_purpose_of_rendering
23:53:17 the layer UI, that's , which already has UI if you use browser debugging tools, e.g dragonfly, firebug or whatever
23:53:41 s/ed: SVG UI/topic: SVG UI
23:54:06 Topic: unknown elements treated as
23:54:40