Web animations minutes, 31 October 2012
Etherpad: https://etherpad.mozilla.org/ep/pad/view/ro.tInrNAaafHh/latest
Present: Shane Stephens, Alex Danilo, Brian Birtles
Agenda:
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?
1. STATUS UPDATE
----------------
Brian:
* 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.
https://www.youtube.com/watch?v=VvNQNtIfXXI
Shane:
* Working through the release process (mainly waiting)
* Going to look at issues with animation groups and animation stack next
Alex:
* 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
-------------------
See above.
3. OVERRIDE STYLESHEETS
-----------------------
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.
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
We have
TimedItem.timing.duration AND
TimedItem.duration
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.
These quasi-inheritance features may be able to use a similar mechanism
to whatever we use for templates.
5. TRIGGERS
-----------
[ Skipped for now ]
6. NEXT DEADLINE
----------------
Meetings:
SVG Sydney F2F, early February 2013 (4th Feb)
CSSWG (same time, Tucson)
FXTF Tokyo F2F, June 2013
FPWD is the next deadline-able 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.
Some previous thoughts about this:
https://etherpad.mozilla.org/ep/pad/view/ro.LIrBvR$UJFL/latest, item 5
Timing for FPWD? Let's aim to have it ready for FXTF review end of 2012.
Next meeting: TBD due to travel and timezone changes