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

On Fri, Nov 2, 2012 at 12:08 AM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Wed, Oct 31, 2012 at 11:15 PM, Shane Stephens <shans@google.com> wrote:
> > Thanks for your response and explanation.
> >
> > It's clear that the two should sit at separate cascade levels, to clarify
> > which wins in the case of an overlap. But it still isn't clear to me that
> > the cascade levels should be non-adjacent.
> >
> > Is there a strong desire for transitions to sit as high in the cascade as
> > possible? What does it buy us? Would it be acceptable to put transitions
> > directly above animations, and below the user stylesheet?
>
> Basically, if transitions are directly above animations, then it's
> *impossible* to transition to/between user!important or UA!important
> rules (and maybe an author!important too, depending on the exact
> placement).  That just kinda sucks.


Right, that makes sense.


>  "Technical purity" of having a
> single override level should probably be below the ability cleanly and
> easily author things that transition like normal, for authors and
> users.
>

Yes, agreed.


> > The problem we are anticipating in Web Animations is that it will be
> > significantly more difficult to implement CSS Transitions and Animations
> > using Web Animations components if the contributions of these two types
> of
> > animation end up being influenced differently by user styles. Ideally we
> > would like to see all of CSS Transitions, CSS Animations and SVG
> Animations
> > acting in a unified manner on a web document to produce animated content.
> >
> > Obviously if there are strong reasons for this difference then we just
> need
> > to cope, but absent a strong reason I think the desire within the FXTF to
> > unify SVG Animations with CSS Transitions and Animations forms a
> reasonably
> > strong reason to keep the cascade levels adjacent.
>
> I'm not sure why, if it's okay to have distinct cascade levels, it's
> hard to have the cascade levels be non-adjacent.
>
>
If the levels were adjacent we could have specified that all transitions
were added to the animation stack before all animations and relied on the
Web Animations animation resolution mechanism to produce the correct
result, which would then be pushed into the cascade.

In order to support multiple cascade insertion points, I think we'll need
to do something like allow animations to be tagged with a priority level
and maintain multiple animation stacks, one for each priority level /
insertion point. It's an open question at this point as to whether those
priority levels are exposed via the javascript API (I can't see any
particular reason why not) / changeable after an Animation is created (this
is probably somewhat problematic) / etc.

Cheers,
    -Shane


> ~TJ
>