Sydney 2012 F2F day 2 -- 11 Jan 2012

<patrickdengler_> i do not have skyp.. hmm

<heycam> patrickdengler_, we'll set up the zakim bridge

<heycam> patrickdengler_, and get cyril to call in to it from here

<vhardy> ScribeNick: vhardy

Web Animations

http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012/Agenda/Animations/WebAnimations

<patrickdengler_> i'll dial in in about 35-45 minutes

<heycam> patrickdengler_, is it ok if we begin on brian's topic and you come in half way through?

<patrickdengler_> please begin brian's topic without me of course

http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012/Agenda/Animations/WebAnimations

brian: this came out of the Seattle F2F to look at the features that are in SVG animations and not in CSS animations and then prioritize them according to usefulness.
... I wrote a long document.
... the first part is in response to the action, about features. This is input to the FX task force.
... I have written it for CSS animations people who do not know SMIL.
... I start by listing the differences. Then I created a few use cases. They may not be sufficient, I would appreciate additional use cases.
... then, I have attempted to prioritize.
... finally, this is what I would like to talk about, is the proposal for an element syntax that is a middle ground between CSS animations and SMIL animations. I would like to discuss the concept and see if there is support.

chris: how does this differ from what Patrick is proposing?

brian: Patrick is proposing to extend the reach of CSS animations in SVG so that you can animation more attributes by making them presentation attributes and animatable by CSS animations/transitions. My proposal looks at adding missing features in CSS Animations/Transitions, such as timing and synchronization.
... Going through what I have written down, here is what is missing from CSS animations.
... Timing. One major difference is that SVG animations have an absolute reference whereas CSS animations start on document load or at the time there is a property match.

dean: yes, this is pretty imprecise in CSS. The actual time is the first time it renders, and CSS does not specify when that time would be precisely. This means forcing a style resolution. There is no real way to kick start the animation precisely.

chris: is there a way to resolve this?

dean: implementations end up doing the same thing and it resolves ok. Things are similar enought that people do not notice.

<TabAtkins> As long as you're not trying to chain animations, yes, it's "good enough" right now.

<TabAtkins> Being able to specifically relate animations to a timeline and/or chain animations together is something I feel is important to eventually support.

shane: because the aniamtions are resolved on style resolution and style resolutions happen at different times, the user may get offsets between animations starts that he/she does not want and cannot control.

dean: the current behavior is kind of ok, but we need something more precise.

shane: I have a question about the SVG timing model. Can you sync. up two animations?

(several): yes.

(several): explain time conditions in SMIL, such as <animate begin="button.click" ..> and <animate begin="myFirstAnim.begin+2s" ... />

brian: in point T1b), there is a description of the features available in SMIL.

<cyril> zakim what is the code

brian: getCurrentTime and then call beginElement, you will get the same time. This could be better specified.

dean: In WebKit, for animations, we don't update/apply different times to the animation in the same script context.
... if you add several animations, they appear to start at exactly the same time.
... CSS does not specify when the animation starts between the time the style is set and when it really kicks in (at style resolution or first rendering).

heycam: in SVG animation, you can specify an absolute time. In CSS animations, you can only specify somethign to start relative to the current time.

brian: yes, that is correct.
... correct sync. with events is possible in SMIL animation.

<heycam> (where by absolute time I mean an absolute time within the document timeline, not a wallclock time)

shane: if we modified CSS animations to better define the time animations start, would that be desirable?

dean: yes.

<ed> Meeting: SVG WG Sydney 2012 F2F day 2

dean: I think brian will go on to explain how an absolute timeline could work.
... I think that is ok. There should be a way to start at an absolute time.

<TabAtkins> Sage.

brian: Below T1 c), I propose ways to have a proper timing, like defining a time container in HTML. We can use inspiration from SVG Tiny.

heycam: we already want a unified notion of time line for requestAnimationFrame and performance APIs, so we should also use a unified notion for CSS animations and SMIL animations.

cyril: why did not CSS animation use a time container to begin with?

shane: because it was defined to start at 'style resolve time'.

brian: my proposal addresses these issues with proposals.
... I propose to consider the timelneBegin, as we have in SVG animation.
... I have a few suggestions to introduce the same in CSS animations.

cyril: this is something we cannot decide here, right?

brian: yes, this is input to the FX task force, an ACTION I had from the Seattle F2F.

<TabAtkins> CSS Animations were defined in a very limited and weak way at first. They simply run as long as the property applies, starting "when the property starts to apply" and stopping when it stops.

brian: we are not trying to decide here now. I am looking for input.

<TabAtkins> By the way, Brian, excellent doc. Lots of food for thought.

brian: moving on to T2.
... in SVG animations, you can schedule multiple intervals. There is only one in CSS animations.

heycam: CSS animations only support something like 'style resolution time' or 'style resolution time + offset'.

brian: yes, that is true, but you cannot control playing the animation multiple times declaratively.
... if introduce that feature, we need to decide how overlaps of the same animation are handled. SVG animations specify how to handle that type of situation.

<TabAtkins> From pure CSS, we'd have to add another at-rule or something that defined an animation separately, so we could tell it to start based on various things.

heycam: in SVG animations, you can have indefinite values in the list, and then you can start the animation with a script call (beginElement).

<TabAtkins> Alternately, create a decent JS API for constructing Animation objects.

<TabAtkins> Or rely on the increasing merging of SVG into the other languages and have an element in SVG for it.

heycam: the CSS equivalent is to manipulate the style to set the animation-name to none and then set it again.

brian: going on to T3, aborting animation. There in an end attribute in SVG animations.
... that is not available in CSS.

<TabAtkins> Note: I do *not* think that extending the power of the 'animation' property is the right direction here for almost any of this.

<TabAtkins> 'animation' does a single simple thing and does it reasonbly well. It shoudl be considered a shortcut for applying animations while an element is in a particular state, not the canonical way to interact with animations.

vhardy: you can abort an animation in CSS, but not declaratively, you need to manipulate the style.

<TabAtkins> imo

<TabAtkins> We should be considering animations as objects separate from the 'animation' property when thinking about how to address most of these.

<TabAtkins> (Similarly, 'transition' does a single simple thing well.)

<birtles> TabAtkins, ok that's good. The "proposals" aren't serious, just showing how these features relate to CSS Animations. Other proposals are very welcome.

chris: Microsoft has expresssed that they do not want to implement SMIL animations. So if we want more features or address the problems, we need to add features to CSS Animations.

<dino> i agree with Tab (mostly - I do think we can extend the animation property to solve some of the things in Brian's document in a simple manner)

vhardy: may be if we can demonstrate that more features are needed and that adding them to CSS animations creates the same amount of work as implementing SMIL animations, Microsoft may reconsider their position?

<TabAtkins> dino: Yeah, some of the things may be appropriate for extending 'animation' - this is a long list. ^_^

vhardy: I also agree that having a common underlying model that different syntaxes / markups map to is the right architectural approach.

<TabAtkins> vhardy: I still doubt that they'd like to implement two separate animation models. We'd like to remove SMIL from Chrome, too - our implemenation is shit and a big security hole.

<TabAtkins> Fixing the security bugs is a "reimplement the whole thing"-level task.

<dino> I do agree vehemently with the goal to not make the CSS syntax for animations much more complex than it currently is. I'd rather go without features in the CSS syntax than make things confusing. I'd prefer a JS API. This goes quadruple for transitions.

chris: people do not want to have SVG animation elements because they want styling and animations seperate.
... the animations could be started from a stylesheet but pointing to a resource where the animations are defined.

vhardy: I think that animations are sometimes content sometimes styling. For example, if you do a cartoon, animations are the content. If applying to an HTML dialog, they are styling.
... also, I think that because there are issues with SMIL engines implementations, we should not conclude that the issue is necessarily with SMIL itself.
... there are a lot of good things in the SMIL model that I hope can be the underlying model for a common animation solution applying to CSS, Scripting (and obviously SMIL).

heycam: I think the SMIL scripting APIs are limited.

vhardy: yes, my point is that if we defined better scripting APIs for animations, we should leverage the same underlying model and use the SMIL timing model as much as possible.

brian: I don't agree an API will solve everything. Sometimes, we need more APIs for animation, but I do not think that will be enough. I think declarative animations is needed. We need a way to do reasonably sophisticated animations declarative animations.

chris: I agree.

vhardy: I agree.

cyril: we've had SVG animations for a long time, they are declarative, and no one is using it. Why are people using CSS animations more, specifically in authoring tools.

chris: there is not much room for a tool for CSS in general, and in particular for CSS animations.
... I do not expect tools editing CSS animations in general?

rik: why not? All the information is there?

chris: I am talking about reading content that was not written by the tool?
... for CSS in general.

cyril: I agree with brian in general. It is better to have a declarative solution for authoring tools.

brian: regarding the adoption, CSS animations apply to HTML and SVG animations to SVG. There is much more HTML than SVG, so that explains the difference in adoption.

<patrickdengler_> There is always this agrugment between declarative and code. Historically, code in browsers meant x-scripting issues. In non-HTML contexts, declarative vs. code has become a bit of a redherring. Yes, tools and tool declarative syntax better, but the harder you push declarative support, the harder it is to understand the concepts, and thus the harder it is to tool them.

<patrickdengler_> Does that make sense?

vhardy: I think one factor too is that CSS animations, at least initially, have been used for UI effects that do not require as many animations and synchronization as you would need for complex cartoons for example. For the types of animations enabled by SMIL, tools are needed and there have been a lack of tools so far.

<patrickdengler_> and untoolable

<patrickdengler_> declarative is still code :)

tab: I agree with Patrick.

heycam: I think the declarative v.s. scripting is a bit off-topic.

brian: the argument put forward is that all we need is a very elementary CSS animation and then a scripting API. I disagree with that position.

vhardy: yes, I agree.

brian: yes, it is not just about tool support. Security is one of the major issues, probably the main compelling reason. You can use animations where you cannot use scripting.
... back to T4 on synchronizing animations. That is in SVG animations and not in CSS.

<patrickdengler_> I respect Brian's well done analysis. My position is that if you increase the feature set of CSS Animations, and back it with a richer API, that this is a better balance long term. That''s all.

brian: there is a proposal to how to add synchronization to CSS animations, it is rough.
... it is a big feature.
... T5. Seeking the document timeline.
... that would be useful in CSS animations as well.

dean: yes, this is useful. CSS animations does not really talk about time containers. So theoritically, each animation is in its own timeline.

brian: T1 may be a pre-requisite for this feature.

chris: having unsynchronized timelines is not useful, because it is common to need to sync. animations.

cyril: do implementations implement time seeks?

brian, ed: yes.

cyril: Is it well specified?

brian: yes, it is decent.

cyril: do we have tests in the test suite for those?

ed: yes.

brian: T6, ability to pause the timeline.
... T7: repeating by duration instead of duration count.
... this might even be more important with time containers.

dean: this is not currently an issue because you always know the duration of children.

brian: it is a convenience, and you can often calculate it and use repeatCount.

dean: what is an example of why you would use repeatDuration?

brian: when you want to sync. on the duration of other animations and not want to compute how many hundreds of iterations that makes in the other aniamtions you are trying to limit in time.
... T8, triggering animations from arbitrary events.

cyril: there is a difference between using the begin event and the begin sync. arc.

<cyril> <animate begin=a.begin> is different from <animate begin=a.beginEvent>

brian: there are differences, the most important one is negative offsets. With sync. base timing, the time will be resolved, but with the event base, the animation will only start after the event has fired.
... there are also differences with seeking.
... so this is the argument for keeping sync. based timing.

<heycam> [brian shows a demo]

brian: showing a demo of a video and an animation sync. up with the video.

<cyril> http://brian.sol1.net/svg/demo/video.html

<birtles> <animate attributeName="stroke-dashoffset" from="9px" to="0px"

<birtles> dur="1s" repeatCount="indefinite" fill="freeze"

<birtles> begin="video.playing" end="video.pause; video.ended"/>

dean: I most cases, I have found writing content to do something like this, you want to triger the event with a conditional expression.
... e.g., you click and some other state exists.

vhardy: when coupled with custom events, this provide a pretty elegant solution, because you can triger animations on application events.

<patrickdengler_> sorry, what?

BREAK for 15mn then continue on Brian's topic.

<patrickdengler_> The only topic I have for CSS Animations is going to be: are we all good with this proposal : http://lists.w3.org/Archives/Public/public-fx/2012JanMar/0003.html

<patrickdengler_> I've not heard any additional feedback beyond Dean's, which is incorporated, and I have otherwise heard support. If this is the case, I'd like a resolution to accept this, at which point I am happy to make the edits in the specification.

<TabAtkins> Yes, I'm good.

<patrickdengler_> If not, let's discuss.

<patrickdengler_> I had hoped to have a prototype to run on webkit, firefox and Opera, but it only runs on IE so far. Once I have the prototype running on all browsers, I will put the code on some open source place so people could drop it in and make their sites backward compatible.

<ChrisL> patrick, I sent some feedback on elevation and azimuth,did you see that?

<patrickdengler_> I saw your feedback on elevation and azimuth. I believe that is included in the link. If I recall you noted that these could and should be deprecated in the CSS Aurul spec so we don't have to rename them. Is that correct?

<ChrisL> yes

<heycam> patrickdengler_, since we're not having an official FX meeting here, are we able to officially resolve that?

<heycam> patrickdengler_, we can say whether we (SVG WG) is happy with it

<patrickdengler_> THat's fine, let's start there though. Dean is good with it and perhaps he can shepard it over to CSS

<heycam> ok

<heycam> we will just wait a few more minutes for vincent to return

<patrickdengler_> I am on the line

<heycam> ScribeNick: heycam

continuing Brian's animation topic

BB: first A1, animateMotion

… that's not possible in CSS

… seems to be quite useful

… we've also already resolved to support a more general case of animation of pairs of values

… that's an abstraction of animateMotion I guess

… (these are animation value features not in CSS)

… next, the ability to combine animation values with underlying animations, instead of replacing

… I think Dean mentioned in Seattle that there's already been some proposal to add something like that

… wasn't sure if that referred to this, or adding separate animations together

CM: what's the difference between A2 and A3?

BB: in SVG they're the same, since they both use the same concept of underlying animation values

… A2 is just considering the base value of the attribute

… A3 is an extension of that where you can have additive animations

DJ: A3 is what has been requested for CSS Animations before

BB: one other difference is that I believe CSS Animations takes a snapshot of the values when it begins animating

… in SVG animations it's live

… if the underlying value changes then the animation will reflect that change

CL: does that mean if the script manipulates an already running animated animation property it doesn't have any effect until the animation ends?

DJ: the only way you could see something happen is if the script manipulates the animation attributes

… in CSS if you have an animation on an element, manipulating colour e.g., if you set the color on the style property of the element it's never going to change while the animation is running

… since the animation always overrides it

… if while the animation is running, you find the @keyframe and update the values there, the animation also doesn't change

… you might expect to be able to change the duration while it's running, but the spec says that shouldn't work

… which gets back to restarting animations, you have to remove and replace it

… which is annoying

BB: another point about A3 is that this is where the animation model comes in, which animation goes on top of which

… some people are not keen on that model

<dino> "As Anne van Karsten points out" - new nickname!!!

… it might be worth reassessing how animations combine together

… the last animation feature is combining animation with itself, that's accumulate="sum" in SVG

DJ: how often is this used in practice?

BB: I suspect not that often

… but I don't really know

CC: what is "SVG's endpoint exclusive timing model"?

BB: that's where at t = 0, the animation effect is applied, but at t = 1 it is not applied

… that's important when you accumulate

… otherwise you'd have overlap

… it's also significant when you have absolute time references

… if you query the animation at that exact end point, the animation is not being applied so the unanimated value will be returned

… now, a couple of other quick items

… document structure -- SVG allows you to interleave animation content with the stuff you're animating

… Anne pointed out that this is possible with CSS if you use <style scoped>

… which noone supports yet

… but will be possible

… I think it's a little cumbersome, not totally convinced by it

<TabAtkins> Chrome is nearly done supporting it.

<TabAtkins> But I agree that it's cumbersome.

… but it is technically possible to interleave CSS Animations with the content

DJ: I would think if we want to add to this wiki document, we should a D2, timesheets

… not interleaving, but still...

BB: I'm just looking at what's in SVG but not in CSS

… it is sometimes useful to separate out the animations from the content though

… now features that don't exist in SVG Animations

… I think if we're going to keep SVG animations, then we really should have time containers

… they give so much utility, the use cases I'm going to present would be easier with time containers

CL: I agree, we were in favour originally

CC: in the 1.2T timeframe we agreed to time containers, but not nested ones

BB: I'm wanting nested ones

CC: you don't want the sync attributes though?

BB: no, just the nested time container elements

… this is one feature that I think is particularly well suited to element syntax, and not so much the CSS syntax

DJ: my hestitation is that it starts putting the animation structure into the document, whereas at the moment where animations are just children of the elemnets you can think of them like decorations to the content

… what this means is what we put into SVG now leaks into HTML

<TabAtkins> Agreed on this being well-suited to element syntax rather than CSS at-rules. at-rules aren't great for nested structures.

… that community less likely wants animation as content

BB: there is a lot of discussion around animation in HTML markup

… I think we want to support animation as content

DJ: actually this doesn't need to be SVG, this could equally be done in HTML

… (animation content)

VH: I believe SMIL originally took a lot from Real Networks

… they were doing a lot of education content, mixing audio, video, overlays, etc.

… so they had a lot of sync work to do

CL: most of that was streaming content as well

VH: so they had a lot of real use cases for doing rich timed multimedia content, the content itself is timed by nature

… it's important to capture the time aspect of the content

CL: one aspect of that would be audio and video, coming from separate sources, and you want the video to sync with the audio

… you care about audio jitter, but not video so much

<patrickdengler_> Side note: I agree, that if you are going to talk about introducing elements to support animation or new animation functionality, you must do it in context of HTML, not just SVG.

… but in other cases you might care about audio being synced to video

DJ: if it's content, you're forcing the author to use it that way. if it's stylistic, you can do it either way.

CL: say if you have some audio/video, some people want audio in some other language, or some people want subtitles

… we've traditionally thought of those choices as stylistic, but it's a slipper slope

… this hard wall of style vs content is more nuanced than is often presented

ack

DS: brian you said that time containers are better suited to element syntax, why is that?

BB: because the proposal I've put forward is arbitrary nesting of time containers, including seq

… in that case obviosuly it's a hierarchical arrangement

… I think as Tab mentioned too, that's harder to do with @at rules

… with an element syntax it's fundamnetally hierarchical

DS: couldn't you have a CSS rule apply to an already predefined container, like a <g> or a <div>?

BB: yes but then you'd need a rule for each <g> underneath that, and you'd need to match up the rules with each of the nested <g>s

… I think that would be cumbersome to deal with

DS: you have to define it either way

… if it's part of the hierarchy, or in a CSS rule applying to a <g>, it's only where you define it

… if you should ever want to change the nature of a time container, or a <g> that has a style rule applied to it, if you want to turn on or off a particular thing, you could do that …

DJ: you could have an excl element, where the author wants it to be exclusive, different audio tracks for example

BB: I think perhaps we don't need to solve this right now

… I'm uncomfortable with the idea of mixing style in that way, where hierarchy is defined in content, but the meaning of that hierarchy is altered by style somewhere else

DJ: it doesn't need to live somewhere else

… you can put style attributes, or in SVG presentation attribtues

BB: if it's a presnetation attribute it's not that different from what I'm suggesting

… I suggested a grouping element, but it could be just an attribute on existing elements

CC: you could use SMIL3 time sheets

DJ: you're right we don't need to solve this now

… but it's an important feature to solve

BB: even if we use CSS rules, we're still relying on element syntax to provide some of the structure

<shepazu> that's fine, I don't need to press the point

DJ: should the element structure also provide new behaviour, in which case you would want to introduce new elements

BB: or attributes
... I have a few use cases which I've already mentioned, not exhaustive by any means

… first is not particularly exciting -- this button

VH: just one comment before the use cases

… I think there's also the ability to target multiple elements, mulitple properties, is not in SVG animations

… but we should support that

BB: there's a lot of stuff that doesn't exist in SVG Animations

… this was just a more detailed version of what I proposed for Seattle

VH: can you point to the Seattle document from this one?

CL: I think the multiple targetting is missing and something we could fix

… dean and others have suggested using CSS selectors to do this

… but the target of the animation is a set of nodes

<scribe> ACTION: Brian to link to the Seattle animation document from the Manly one [recorded in http://www.w3.org/2012/01/11-svg-minutes.html#action01]

<trackbot> Created ACTION-3201 - Link to the Seattle animation document from the Manly one [on Brian Birtles - due 2012-01-19].

BB: let's go through the use cases quickly

… this button example was made to emulate a Flash button as a challenge

… in order to do that, I've listed the features of SVG animations that were useful

… multiple intervals, declaratively aborting animations, synchorising animations, triggering from events

… time containers would have made this example much easier

… this one, why not do it with script? might be a fair call for this example

… generally with UI widgets it would be nice not to use script for the hover interactions etc.

… next use case is more complex, a WIP

… this is something we're doing for an event in a couple of weeks in Tokyo

… there's an animation group that do workshops

… they give everyone tablets where people create frame based animations

[brian shows animation webapp example]

… it's a collaborative project where the animations are uploaded and then combined into a display

CL: can you publish this?

BB: it's not quite ready, after the event in a couple of weeks

… the features this example uses:

… absolute time references, to insert the animations

… synchronising the frames together, the ones you draw yourself

… repeatDur

… motion on a path

… and combining with an udnerlying value

… time contaienrs again would be useful, for the frame-by-frame animation, put them all in a <seq> container

… one interesting thing with this, being declarative is an advantage

… (though we are using script as well)

… we'd like to be able to email peoples' characters to them, as a souvenir

… can't run script in a mail client

… when we embed subanimations in a master animatino, that's using an <image> element, and you can't run script in there

… finally, example 3

… an in progress animation tool for cutout animations

[brian demos moving little parts of Foxkeh arround]

CC: like Terry Gilliam's animations

BB: this uses setCurrentTime, getAnimVal, etc.

CL: it's a classic cell frame animation kind of thing

<ChrisL> Classic cell-frame animation

BB: so now I have a prioritisation of animation features based on these three use cases

… a tentative prioritisation

… this is my assessment of the bigger items to handle

… these are the features in SVG animations not in CSS animation that we could bring over, prioritised

CL: synchornising multiple video and audio streams from different sources is a different use case, but it uses the same features as these other examples do

CC: no, you need the runtime sync attributes, syncBehavior, syncTolerance

… they're different

… time containers are containers that have a clock associated, they can be nested or not

… and they can be of different type, par vs seq for example

… then there's how does the clock behave when it drifts, they're the sync attributes

… in 1.2T we have time containers, there can be multiple timelines

CL: and they're implicit <par> containers?

CC: and we have the sync attributes

CM: should we be bringing all these features over from your list?

BB: not sure, motion on a path and time containers for example might be hard to realise in CSS syntax

DJ: we get a lot of requests for motion on a path

… I agree with your suggestion, it's almost like a special case of transform animations

… I don't know how to represent that, though

… don't like extending animation syntax just to do motion on a path

BB: this is just input for the FX taskforce

… it needs further discussion

… but things towards the top of the prioritisation list are probably more useful than those towards the bottom

<patrickdengler_> I am

<patrickdengler_> Is it time for my topic :)

CM: I wonder if Patrick has any views on the set of features Brian has identified

… and whether all or some should be brought across to CSS

<patrickdengler_> I am by far no expert in animation.

… it's probably not something we can decide right now though

… but would like to hear his views

<patrickdengler_> I love the idea of enhancing animations, but not to the extent where it overloads the syntax such that is unusable (opinion)

CC: I want to know if there's any impact on our SVG2 requrirements decisions

<patrickdengler_> Any impact of the proposal? no

<scribe> ACTION: Brian to prepare before and after examples of using time containers in SVG animation [recorded in http://www.w3.org/2012/01/11-svg-minutes.html#action02]

<trackbot> Created ACTION-3202 - Prepare before and after examples of using time containers in SVG animation [on Brian Birtles - due 2012-01-19].

<patrickdengler_> Woot!

CSS animations targetting SVG attributes

<patrickdengler_> I just want to see if we can get a resolution on the proposal I sent out

<patrickdengler_> It's very basic and orthogonal to all of these other discussions.

patrickdengler_, got a link? is it this? http://www.w3.org/mid/D7C8ABF3132F9D439385C55C1955D82DE3399C@TK5EX14MBXC294.redmond.corp.microsoft.com

<patrickdengler_> It is one of the three options we discussed for moving CSS animations on top of a select few, targetted attributes

<vhardy> http://lists.w3.org/Archives/Public/public-fx/2011OctDec/0168.html

patrickdengler_, as there were a few options, can you briefly summarise which one this was? i.e. what set of attributes it targets and how it does it?

<patrickdengler_> The last few open issues that I knew of were semantic and type collision resolutoin wasn't acceptable and I agreed

<patrickdengler_> THe set of attributes are in the link above

<patrickdengler_> Only 4 had collisions.

<patrickdengler_> azimuth and elevation, which were both parts of a CSS Aurul specification, that ChrisL said we could deprecate in that specificaion (correct?)

<patrickdengler_> transform, which dean has started a nice proposal through implementation, and which has other implicatoins outside of the scope of this proposal

patrickdengler_, I'm having trouble refreshing my memory -- was this the proposal to upgrade attributes to properties, with the same names as the svg attributes?

<patrickdengler_> Yes.

CL: I object to upgrading attributes to properties

… I think instead we should "treat" these attributes as if they were properties

… for the sake of CSS animation

… that's a big difference

… if we make randomly every single attribtue in SVG (practically) it means they apply to all elements

… and things like x and y which don't make sense on most of them, it's a bad idea, leads to a lot of bloat

<patrickdengler_> wait

… whereas the same proposal, but with a slight wording change

… taking a mechanism that was originally designed to work only with properties, and let it treat SVG attributes as if they were properites for the sake of animation

<patrickdengler_> this is not right

<patrickdengler_> Does font-size apply to circle?

<patrickdengler_> we have properties that don't apply to elements.

DJ: so you wouldn't be able to style these attributes with CSS unless you were animating

<patrickdengler_> What does property bloat mean? If you are thinking implementation that argument doesn't apply.

… and you wouldn't be able to use Transitions on them

<ChrisL> would mean that the attributes are *treated as* properties for the sake of CSS animation

<ChrisL> no real impact on the proposal itself, just a change in terminology

VH: I understand Chris' point, but I htink from an authoring point it would be confusing to target them from animations but not be able to put them in a normal style rule

… if you can put x in one place but not in others

<patrickdengler_> They have to be properties

… that would be confusing

CL: so yes it has differences on these other side effects

… not transitioning is a negative side affect, I agree

DJ: I think transitioning is important

… transitioning a circle radius would be very useful

<patrickdengler_> Transitioning is key and part of the proposal

CL: the CSS WG would not be amenable to adding many properties

<patrickdengler_> You cannot separate them. The proposal is to make them properties.

VH: this needs to be taken to the FX, yes?

… can we bring it to the TF, if we all kind of like the idea, but there are concerns about adding that many properties, and ask for their input?

<patrickdengler_> This has been taken to the FX group; I have shared it on those threads. Everyone has given feedback and agreed (including ChrisL). What other magic do I need to do?

… we can bring up Chris' issue in a real FX setting

CL: I just think this had a lot of downsides and there's another way to do it

… we need to weight up the pros and cons of this approach

CL: no, I didn't say I agreed to the whole thing, just the specific point that was asked about

… I'm not objecting here

… I'm just saying we should consider another way forward

VH: to answer patrick, for a decision we need to make that in an FX setting

… not that it hasn't already been brought up there

CM: I think we should get our SVG's view of it

… to make half of that decision

<patrickdengler_> I dropped off hang on.

<vhardy> VH: I agree

<patrickdengler_> I cannot get back on the line.

<patrickdengler_> I am totally lost on process here.

<patrickdengler_> The FX group has already sent all of the feedback; the FX group is all present here correct?

patrickdengler_, no I don't think all of the FX group is here

VH: david baron isn't here

<patrickdengler_> Can you set up another conf?

<patrickdengler_> #

… I think he will still have issues with this

<TabAtkins> It is slightly troubling from a CSS perspective to add a bunch of properties that apply to only a single/few elements each. Most CSS properties are relatively widely applicable.

… Tab also

patrickdengler_, yes

PD: this discussion has been going on for over a year

… hundreds of emails

… at every meeting I've written up proposals, presentations

CL: I didn't say it was no good

… I said the vast majority was fine, just concerned about the side effects of it

… I proposed something that mitigated those side effects

… I just want to talk about that

PD: we discussed property growth last year, and we've addressed that

… we definitely need transitions to work

CM: I don't get the sense that anybody wants CSS animations not to work on SVG attributes

<TabAtkins> I'm pretty happy with the actual property set we've done so far.

<ed> TabAtkins: what property set do you mean? the one that's in CSS transitions?

<TabAtkins> I mean the one that was proposed by Patrick. It's only a handful of properties. Once the few collisions are handled better, which has gotten good suggestions, I'm pretty happy.

[discussion of process on how to move forward]

DJ: patrick has done a lot of work, getting private and public feedback

VH: there are two things, one appreciates all the work you have done

… the point about making the decision in the FX setting, if we make a resolution today it's just a technicality

… a final recorded decision needs to happen in the FX group

CM: we should go through each of these proposed resolutions

CC: I feel like if we agree to this proposal, or even say Brian's proposal, it's the end for SVG markup for animation

… that's how I feel

… people will use CSS Animations to target animations

… it's like we're deprecating SVG animation elements

DJ: not really, we're giving people a better way to animate content in some cases

… I think you're implying that because we're going in this direction, it's deprecating SMIL

… I don't think that's the case

BB: just extending the reach of CSS animations doesn't jeopardise the usefulness of SMIL

CC: we'll just end up with two tools for the same thing

DJ: we should have discussed this a year ago

… we've been discussing how to do this, not whether it should be done

… in general, most people want to be able to do CSS transitions and possibly animations on SVG content

BB: and you already can for style properties

DJ: yes, and we have a specially worded spec so you can do it for transforms now

… but even with that, there's a bunch of graphical parts of SVG that's not exposed

<TabAtkins> I think we shouldn't worry about hurting SMIL's feelings.

VH: for the sake of progress, we have 20mins here, and we have multiple issues, I propose if somebody has an issue with one of these resolutions we do that now

… and if not, we assume it's ok

[mention issue #1]

CL: I agree with that resolution, we should keep the existing names

VH: for width, you could have a width property that applies to <rect> and to <div>

CL: that's a separate problem

… width/height in SVG are not the same as those in CSS

… they mean different things

… that's the reason why SMIL had attributeType

DJ: I don't think there's much chance someone would write a stylesheet that sets width on <rect> and root <svg>

CM: it doesn't inherit

<patrickdengler_> (I can no longer hear on the phone)

issue #2

CM: we have already resolved to fix this for SVG2

… so this issue isn't a problem

CL: yes, we've already decided to unify the syntax between presentation attribetus and properties

issue #3

[discussing style vs content briefly]

CL: if implementors think promoting to properties is not a problem, then it's fine

… I don't have a problem with promoting to properties if implementors are happy with it

CC: when I implemented SVG, there is already a burden with style resolution and propagating values down the tree

… it's not a big burden

… I'm just wondering how much worse this will make it

ED: I am wondering too, we'll just have to implement and see

CL: I'm guessing most implementors do this with a big table with all the values
... these will most (all?) be non-inherited properties

<patrickdengler_> non-nherited

… in terms of propagation through the tree, the scope of impact is limited

CC: unless you set "inherit"

CL: yes you can always put "inherit"

CC: so all these properties would allow "inherit"

CM: and "initial"

… but I don't think that's a problem

DJ: we converted transform to a property

… and that property already existed

<patrickdengler_> tada :)

… so we can't use that as an indication for how much impact there is

… the webkit prefixed transform property applies to SVG elements

<cyril> how many properties are we talking about?

CM: so there's 47 properties in the proposal table

CL: oh so no it's not all animatable attributes?

CC: no, just a limited set

ok so there's no implementors in here saying they definitely have a problem with promotion, in terms of performance impact

we can move on

issue #4

<patrickdengler_> You just answered #4 I think

well we need to be happy with that particular set

patrickdengler_, what is the actual set there, as a summary?

<patrickdengler_> The summary is in the proposal

<patrickdengler_> It is scenario driven

VH: it's a good set of properties

<ed> I would like to see the excluded property set

<patrickdengler_> It is based upon the use cases I presented.

<patrickdengler_> I can produce that, but not tonight.

CM: I don't think the particular set matters right now

<patrickdengler_> I am not against promoting others, I was just trying to restrict based upon use case and to avoid collsions

CL: I think CSS people will complain about overgeneric names like z, but we already have overgeneric names like "color"

<ed> patrickdengler_: that's fine, but I think it would be good to include that set too, for completeness

CM: so I'm happy that patrick has come up with a reasonable set of properties here

issue #5

CC: what if I put 'x' on a <g>, and then I have a <text> underneath it

… what's the rule?

<patrickdengler_> X doesn't apply to g does it?

sorry I meant to type <svg>

CM: I would prefer not using different names in case of conflicts

… just define what happens if you have <rect style="x: 10px 20px">

… that's better than coming up with different names, which is something new for authors to learn

patrickdengler_, I'm having trouble reading your proposed resolution here, what is it?

<patrickdengler_> For this case, it is just as was suggested. Define what happens if you have <rect style=

<patrickdengler_> "x:10px 20px"; that should be a css rule already no?

<patrickdengler_> (i.e. what if I put left:20px 40px

<ChrisL> patrick, whose comment is the capitals, red text in your document

no because you need to have the single x property defintion take the union of all possible values

<patrickdengler_> I think the comments in red (if you are looking at my last sent one) are Dean's

so anyway, I think we don't get this for free from CSS, but we just need explicit wording to say what happens when you do <rect style="x: 10px 20px">, which is fine

<patrickdengler_> I don't konw what you mean by having a single x property take the union of all possible values. Sorry, not an expert, just trying to solve a problem :)

CL: I think that's the right approach

patrickdengler_, I don't think you can have two separate property definitions for when they apply on different elements

patrickdengler_, because properties are universal

patrickdengler_, but I think it's not a problem, and everyone here agrees

issue #6

CL: so this is only in the case of conflict with existing properties?

CM: in practice the only problem with font-size and the font shorthand?

CL: yes

<patrickdengler_> azimuth and elevation as well but CL and I dicussed that one (if he can elaborate)

CM: so what about width and height? we allow unitless values there?

patrickdengler_, would we allow <rect style="x: 10">?

<patrickdengler_> I think this problem already exists (?) in SVG, and unless there is a unit type, it isn't valid

patrickdengler_, I'm not sure from reading the proposed resolution

<patrickdengler_> I wouldn't change CSS here; I would force SVG for lengths to require unit types.

patrickdengler_, right that is currently the case

patrickdengler_, but not in presentation attributes?

<patrickdengler_> (but not for floats)

<patrickdengler_> (unless css introduces this)

VH: I think it might be confusing for authors not to allow unitless values for these promoted attributes

<patrickdengler_> I think they'll figure it out

CM: this confusion already exists though
... so I don't think it matters for acceptance of this proposal

everyone here happy

issue #7

<patrickdengler_> Issue #7 I resolved slightly differently, and it now falls into issue #5 category I think

I don't think this is right

<patrickdengler_> (it should be at the top)

yes, so because of issue #5 we have a single universal property definition

in that example you quote, the second rule will always win

and then we just define how it behaves if applied to an element that only really wants a single value

patrickdengler_, that make sense?

<patrickdengler_> Yes

issue #8

we are ok with the particular set

RESOLUTION: The SVG WG is happy with Patrick's property promotion proposal for targetting SVG attributes with CSS animation

<patrickdengler_> I LVE YOU ALL

CM: we should mail the fx list to say that the SVG WG is happy with the proposal

<patrickdengler_> That would be great!!!!

… schedule an FX call in a couple of weeks (since some of us a travelling)

… so that we can get their agreement too

… hopefully that mail about our acceptance of the proposal stimulates concerns to be brought forward from the CSS folks

patrickdengler_, we might break for lunch now then

<scribe> ACTION: Erik to mail FX list with our acceptance of property proposal and to schedule a call [recorded in http://www.w3.org/2012/01/11-svg-minutes.html#action03]

<trackbot> Created ACTION-3203 - Mail FX list with our acceptance of property proposal and to schedule a call [on Erik Dahlström - due 2012-01-19].

-- break for lunch, 1hr --

<shans> ChrisL: http://code.google.com/p/experimental-css/

<cyril> scribe: Cyril

<scribe> ScribeNick: cyril

Matrix API

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

DJ: the idea is that when you're doing a lot of txf maths in matrix, the overhead of writing your own matrix class
... is annoying
... 1) because of the performance
... 2) because the API is immutable you create a lot of objects that you'll throw away
... 3) converting to and from a CSS transform because you go through the string API
... this is a proposal for a 4x4 matrix API
... I removed skew
... i hate skew and there are other ways to do skew
... there are 4 constructors
... Float32Array close to the WebGL
... it's defined in the type array spec
... it could become a JavaScript type

CM: in WebIDL you can't override if you've got 2 types and they are both array or sequences

DJ: but that's not a problem

CL: how do you do perspective ? you have to go to 3d (4x4)

DJ: yes
... there should be a perspective function
... for rotation, scale and rotation functions, there is a mutable and immutable version

CM: since it's multiplied by it should be inverse of

DJ: rotate, rotateAxisAngle

VH: shouldn't we have the angle value before the x,y,z value

DJ: I'm not sure SVG takes degres

BB: should there be an immutable version of leftMultiply

DJ: because it's immutable and returning a new matrix, you can do it

CL: I think it's worth adding a comment on that

DJ: typically people won't use the immutable versions

VH: there is no center in the rotations

DJ: right, we should have that
... same for scale from origin
... then there are 3 conversion functions
... getting the float32array

<heycam> dino, you should write "stringifier;" rather than "DOMString toString();"

DJ: David and Robert made this comment, they want to add units
... because if you've zoomed the page,
... you don't know the units

<dino> feedback from Simon Fraser: It's problematic to pretend that you can convert matrix() from getComputedStyle into a 4x4 unitless matrix, because you don't have any context that tells you how big a pixel is. This means that it breaks down if full-page zoom has been applied.

CM: is the issue that in the actual property you can't put units ?

DJ: this API is just about matrices but the problem is when you try to mix it with CSS TRansforms

<ed> just a note, the SVGTiny12 uDOM has an SVGMatrix interface that has methods that mutate the object

<ed> http://www.w3.org/TR/SVGTiny12/svgudom.html#svg__SVGMatrix

CM: an example is if you have scale(2px)scale(3em) and exposing that as a matrix with unitless values
... then it's going to work if you put that back to the same element

because of the em computation

VH: what's our goal here?
... are we collecting feedback
... or solving the issues

DJ: I'm taking notes and will produce another version

VH: maybe we should have a way to set the txf center instead of adding a parameter

CC: but then it becomes stateful

DJ: and it becomes a transformation class instead of matrix

CM: is it going to be exposed when you get the transform property?

DJ: this could be substituted to CSS Matrix or SVG Matrix
... it wouldnt be returned by the transform property but accepted by the setter and the same for other SVG properties
... people have requested a way to decompose it

VH: does it return an array of matrix

DJ: we'll have to define another class
... so that's why I left it out for the moment, like lookAt that needs a point/vector class
... lookAt is a different way to do rotation without angles

CM: can you use the CSS animation to do that camera rotation?

DJ: yes
... you would have to decompose into rotation yourself
... for an object rotating around another, it'll be possible but for translation at fixed velocity, it would be hard

VH: you could nest it

<shepazu> (how else can you do skew x/y? they aren't great, but the best way I know to make pseudo-3D shapes in SVG...)

DJ: I've removed skew and I hope people are happy

CL: the way to do skew is to go 3D

RC: but people like pseudo 3d

DJ: the only good use of skew is asymmetric diagrams

s/asymmetric/isometric/

VH: I don't have a good feeling about removing skew

CC: it's possible with the matrix coefficient

DJ: yes, I'm not giving the shorthand for that

<heycam> shepazu, this is just the Matrix API -- you can still put skew as a transform item in the transform property

VH: have you looked at the apis that provide skew or not ?

<heycam> shepazu, (and of course it's always possible to set the components yourself; mind you I have no opinion on not having them)

VH: if it's popular, I would keep it

CL: no problem to changing to degrees?

DJ: no

VH: what is ortho?
... projection that is not perspective
... in GL you give the frustrum (near, far)
... in general, for GL use, people will port GL code and reuse it

s/frustrum/frustum/

scribe: in CSS we do have a perspective which is one coefficient in the matrix
... that's different from what most people do in GL

RC: maybe we should build a graph of operations, under the hood

DJ: that's interesting
... anyway, we're starting to implement that in WebKit

BB: where would that be used ?

DJ: WebGL code
... they get hit by 2 things: matrix and garbage collection

BB: what's the relation with SVG?

DJ: it's more an FX item
... but maybe some SVG people would benefit from that (D3 ?)

BB: SVG is 2d, what's the benefit of having a 3d

DJ: maybe none, maybe there would be an overhead
... the biggest benefit is the mutability

ED: SVGT1.2 has it already

<ed> http://www.w3.org/TR/SVGTiny12/svgudom.html#svg__SVGMatrix

CM: is it part of the idea to move SVG and CSS matrix together

DJ: it's not designed as a replacement
... in a perfect world, there should be a single matrix class
... but both are already quite different

<krit> dino: which matrices differ, and how? SVGMatrix and CSSMatrix?

<dino> krit: yes.

<krit> dino: SVGMatrix has more functions, but I don't see where they would differ beside that

<krit> dino: the additional functions don't influence the current matrix

<dino> krit: i was just saying that they are different now. they have different api

<krit> dino: I would rather like to make them more common

<dino> krit: that's exactly what we're trying to do

<krit> dino: SVGMatrix could inherit from CSSMatrix

<krit> dino: ok, "... but both are already quite different" sounded like you want to sperate them more

<krit> dino: so just a misunderstanding

CM: this matrix class you would use it in all place where CSSMatrix is accepted

DJ: not at the moment, it's more a standalone API at the moment

CM: what's your view on other standalone classes (point...)

DJ: it would be great if it would exist (dot product, cross product ...)

CM: I'd like to see more general APIs

DJ: but it's poluting the JavaScript namespace in browsers
... who are we to put things in the global namespace in Javascript ...

<krit> soecification writer?

DJ: that's why I called it Matrix4x4 instead of "Matrix"

<dino> sure - i was just suggesting that we should be careful to add things into the global namespace

<dino> without asking them

<dino> krit, yes. I support merging SVGMatrix and CSSMatrix. I dont think Matrix4x4 is the right place to do that (maybe it is)

Compositing

<cabanier> email: http://lists.w3.org/Archives/Public/public-fx/2011OctDec/0150.html

<shepazu> we could talk to TC39 about adding Matrix to JS space… there are some who want to see tighter integration of JS with the Web usage and DOM (e.g. Alex Russel)

<krit> dino: if you plan a common Matrix API, why not?

RC: here are the mail of last months
... I'd like to split the spec into 2

<dino> krit, i was simply worried that it would become a monster of 3 apis :)

RC: people agree that there will be 2 keywords
... 2 properties: alpha-comp and blending

<krit> dino: I support your proposal

<heycam> ScribeNick: heycam

RC: blending does not do compositing, it takes the source image, calculates the background, then produces a new image

… which is then composited on to the background

… you don't composite first then blend

CC: but the blending only applies to the regions where there are two inputs to work on

DJ: no

RC: the compositor figures it out for you

… blending calculates an image

CC: based on two values, right?

DJ: based on the background and foreground

… and they only exist in the area the compositing operations has a result

DJ: the background always has a value

CL: it might be transparent black, but it always has a value

VH: are you thinking of examples like clear?

RC: the background is calculated by taking all the …

CC: if you take what's in the spec now, it uses four parameters

<ChrisL> thread at http://lists.w3.org/Archives/Public/public-fx/2011OctDec/thread.html#msg150

RC: part of splitting up means that the compositing function and blending function are separate

CC: what we said on the list was that there's no split of the model, the model only has one equation

… the two properties control different aspects of it

… the alpha-comp controls compositing modes

… the blending property controls the F function

RC: it's the other way around

CC: let's work offline on this

<ChrisL> Cyril: According to the current draft: src-in is f(Sc,Dc)=Sc and X=1 and Y=Z=0. Multiply is f(Sc,Dc)=Sc x Dc and X=Y=Z=1. So you are saying that when you use both the compositing and the blending modes, you keep the value of f(Sc,Dc) from the blending and you keep the X, Y, Z values from the compositing mode.

RC: this splitting helps remove a lot of duplication

<ChrisL> quote fromalex: "By separating out the blending from the P-D you get more

<ChrisL> combinatorial possibilities that you couldn't do nicely if it

<ChrisL> was one property."

… in the spec it says a <g> introduces a new stacking context, but nobody does that

RC: another one was simplifying porter duff by removing clip-to-self

… we'll also add the missing blend modes from PDF/illustrator

… there was discussion on whether to have knock out or not

… we should clarify its purpose in the spec

[rik draws to explain knock out]

DJ: so it's almost like group opacity in some wys

s/wys/ways/

RC: it's the opposite of "isolate"

DJ: it's like doing a clear of the shape in the group with knockout, before the blending operation happens for the child, so that the child only blends with the group's background
... for porter duff, how useful are they other than clear, srcover?

CC: some designers use src-in, dst-in

VH: I think originally porter duff was done for video, matting

BB: I think also for tiling of images using atop to avoid seams is useful

VH: I think from an implementation perspective, if you do one you may as well do all of them

RC: I'm not completely convinced that porter duff should be in the spec, it feels a bit like a filter

… it's already in the filters spec

… in a way it makes more sense there

DJ: but it doesn't allow you to clear an object, the way it exists in filters

… the result of a filter is always src-over composited

… if you want to knock out a background you can't do it

RC: background doesn't really work with porter duff anyway

… when you do compositing you don't look at the background

DJ: what is this compositing with?

RC: there are two images

DJ: in SVG, you would say <circle id="a'/><circle id="b" comp-op="src-in"/>

[vincent does some drawing on the board, and rik mentions that he proposed to remove clip-to-self property, and have clip-to-self be the default (only) behaviour]

DJ: my next question, we don't do the missing blend modes

… we don't have hue, saturation, colour blend

RC: those ones only work on rgb, not cmyk

… maybe that's why apple doesn't have them

DJ: we are creating a new stacking context when you use a blend?

RC: yes

CL: on the mailing list, alex suggested a different name for comp-op

… eventually he said what about "shape-mode" or "blend-mode"

VH: we agreed in seattle to do a CSS Compositing spec, generic and not just SVG

… I understand enable-background:new being the default for SVG, but it's less clear in CSS

RC: any time you have a non src-over comp-op, you imply enable-background:new

… that's new

DJ: that's confusing

<scribe> ACTION: Rik to write a small example explaining alpha comp and blending [recorded in http://www.w3.org/2012/01/11-svg-minutes.html#action04]

<trackbot> Created ACTION-3204 - Write a small example explaining alpha comp and blending [on Rik Cabanier - due 2012-01-19].

ACTION-3204: explaining also how knock out and enable-background work with them

<trackbot> ACTION-3204 Write a small example explaining alpha comp and blending notes added

DJ: my main comment is, can we please have this in a spec?

… I don't mind if people disagree with it, but currently you have to read one spec and 20 emails

RC: ok

… we might also reword the alpha compositing section of the SVG spec

… wrt enable-background

… I think the Filters spec is a lot more readable than what's in the SVG spec

DJ: I think the spec needs to have more description for every property

CC: I don't think I agree with the removal of clip-to-self

Web Animations

BB: I have a proposal in light of the features we discussed this morning

… that proposal is to make an element syntax that tracks CSS animations

… in many ways

… in terms of properties and behavior, matching names

… but also borrows from SVG animation as well

… it's a more fully featured CSS animations, in that it offers things with hierarchical semantics

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012/Agenda/Animations/WebAnimations#Proposal:_Web_Animations

… compatct syntax, motion on a path, simple DO manipulation

… I've called it Web Animations

… I'd hope we could end up with one spec with two syntaxes

… but the CSS syntax would probably be less fully featured

… as Patrick mentioned, we don't want to overload the syntax to the point that it's a pain to use

… from that core set of functionality, we only include the core stuff in CSS and the more complicated/sophisticated would only be available in the element syntax

… the precedent for this arrangement is filter effects

CL: I think that's a reasonable approach

… the CSS guy are very concerned about simple use cases, authoring

… they seem quite keen that if it gets too complex you go to something else (like element syntax)

… I think that's a reasonable split

BB: I think the other thing it offers is the ability to divide between semantics and styling

… you can use CSS syntax for a presentational flourish

… but for content you could use element syntax

… what I'm proposing is the one model, moving easily between the two sytnaxes

VH: I like the one model approach

… one question I have is that in my expereince we have well known problems in animation

… there's a timing model, animation value, the syntax is almost orthogonal from those

… SMIL covers a lot of that

… the animation engine really is going to say "here are properties that are animated, the from/to values, keySplines, iterations, etc."

… could we agree to say that the precendent to follow is to reuse as much as possible the SMIL model?

… but choose the best syntax for that?

I'm sure SMIL is not perfect

s/I/... I/

… I'm afraid of going down the path of reinventing SMIL

… I'd much rather do the easy way of using the SMIL model

… I'm asking that for any aspects of the model we need, we take it from SMIL

BB: I'm proposing something that learns from SMIL but is not bound by it

… one of the big questions is to have something new that breaks compat

… that's what I'm suggesting

CL: I agree we shouldn't go off an reinvent the whole animation model, the stuff which has been proven to work we should reuse

BB: I'm talking about breaking compat with SVG 1.1

… introducing a new element that contains the simplified behaviour, more aligned with CSS

… not building on <animate>

CL: I'm less concerned about syntax than the underlying model

BB: there are some things like how rounding is done differently

… it's not easy to say in SVG2 rounding is done differently

… that's why I'd prefer a new element

CC: you'd throw away your animation engine in firefox?

BB: no

… in the future perhaps deprecation would allow removal of the old elements

BB: I want to see if there's any agreement on that concept of defining a Web Animations spec

-- adjourned --

-- discuss more about this tomorrow --

DJ: I'd like to see javascript apis too

- DRAFT -

Sydney 2012 F2F day 2

11 Jan 2012

Attendees

Contents

Web Animations

continuing Brian's animation topic

CSS animations targetting SVG attributes

Matrix API

Compositing

Web Animations

Summary of Action Items

Scribe.perl diagnostic output