Server Notice:


Public Pad Latest text of pad qofNpnHRHQ Saved Oct 31, 2012

Meeting 31:
1. Status update
2. Licensing update
3. The current proposal for override stylesheets makes it impossible to update CSS transition endpoints in a User Stylesheet without destroying the transition. Is this what we want?
4. I want to look at the handling of linked animations one last time and confirm we've made the right decision.
5. I'd like to look at animation triggers again, specifically with regards to whether triggers are compatible [with] multi-threading
6. What is our next deadline?
Present: Shane Stephens, Alex Danilo, Brian Birtles
* I'm travelling from 2 Nov to 20 Nov and less able to meet up. I'm planning to do a lot of work on Web Animations after that.
* As far as I can tell we're pretty close to having the shim ready for release. Shane's just waiting for approval... and then he's got to wade through all my messy pull requests... sorry!
We'll be using GitHub plus the Google CLAs. Dmitry and I have completed or are already covered by existing CLAs so we're good to go.
* I made an annotated screencast of the demo. Feel free to share and send feedback. If I get a chance I'll probably put on a blog in the next day or two.
* 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.
See above.
As currently specified
in the Author stylesheet:
.foo {
    width: 100px;
    transition: width 1s;
.foo:hover {
    width: 200px;
in the Override stylesheet, for 1s,
.foo:hover {
    width: (varying from 100px to 200px over a second);
in the User stylesheet:
.foo {
    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.
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
We have
TimedItem.timing.duration AND
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.
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)
Previous thoughts: item 5
Timing for FPWD? Let's aim to have it ready for FXTF review end of 2012.
Next meeting: TBD