[web-anim] Web animations minutes, 31 October 2012

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

Received on Wednesday, 31 October 2012 05:34:23 UTC