* Working through the release process (mainly waiting)
* Going to look at issues with animation groups and animation stack next
* Brian and Alex gave a _kick-a$$_ demo in Tokyo. It was so good that people's heads were exploding. LITERALLY EXPLODING.
2. LICENSING UPDATE
3. OVERRIDE STYLESHEETS
As currently specified
in the Author stylesheet:
transition: width 1s;
in the Override stylesheet, for 1s,
width: (varying from 100px to 200px over a second);
in the User stylesheet:
width: 150px !important; // this beats override stylesheet and therefore clobbers transition
transition: width 1s !important; // even if !important is inserted into override stylesheet based on this, override !important is still < user !important, so transition is still cloberred.
Basically this means you can't change a property that is transitioned without clobbering the transition.
This is what Tab says about Firefox's model, which the WG looks likely to adopt:
(FF's model is that animation and transitions both create "magic
properties" at specific levels in the cascade. Animations work just
above normal author rules (below author!important), while transitions
work above everything.)
We don't currently distinguish between Animations and Transitions in Web Animations.
Action: Shane to discover why DB thinks this is important
Need to look at DOM animation, @attr too.
At Tokyo we had a question about whether changes from animation are inspectable via the DOM. For CSS, we have been having this discussion about override stylesheets (which are reflected in the computed style) and for SVG we have animVals (which everyone hates) to make the animated values inspectable. But for HTML attributes what do we do?
For now we are suggesting using a custom animation function which will just override the base value (i.e. probably won't be additive etc.) But in the future we will certainly need to address this use case. One concrete example is animating the level of a <meter>. The attr stylesheet discussion (@attr) will certainly overlap here and is something we need to watch out for.
4. LINKED ANIMATIONS
Some of the proposals we've looked at wrt what to do if a timing value is modified on an animation that is linked to a template:
1) throw an exception
2) modify the value in the template (and hence in all other linked animations)
3) unlink the modified animation
4) override just that value for the modified animation
We have chosen 1. Is this definitely the right choice?
4 is the most intuitive, but we did come up with specification / implementation issues when we tried to make it work. Reversing was the main issue because reversing requires modification of timing things.
There's a consensus to revisit 4.
There was also an issue with knowing if values are inherited / being able to reset them / this causing API bloat.
Action: Shane to suggest an API for this.
We also need to consider if we can reconcile the "inheritance" going on between Timing and TimedItem
e.g. for a group
If TimedItem.timing.duration is null then it means "use the intrinsic duration" which for a group is calculated from its children
TimedItem.duration is effectively the calculated value and so should not be null
The other property is animDuration which is writeable and overrides the calculation of the animation duration if set.
6. NEXT DEADLINE
SVG Sydney F2F, early February 2013 (4th Feb?)
CSSWG (same time, Tucson)
FXTF Tokyo F2F, June 2013
FPWD is the next deadlineable thing. That requires knowing where we're going with Media integration.
ACTION: Shane to look at Media integration closely.
Synchronization is also an issue. Might need something out-of-band for dealing with media controllers. e.g. Can't necessarily move a video into a sync group easily because it's a separate presence in the DOM.
Alex got feedback about WebVTT as well - want to make sure we allow for that.
(Brian proposes simplified sync-base timing. Shane dies inside vomits a little in his mouth)