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

On Nov 8, 2012, at 5:31 PM, Rik Cabanier <cabanier@gmail.com> wrote:

> Is there a need to define a complex model that describes how animations and transitions interact?
> 
> During TPAC discussion, David Baron mentioned that it would be a lot easier if you just let animations 'win' in case there's both an animation and a transition on the same property. 
> This seems much easier for a user to understand. (I believe Chrome already does this)

I think David wanted it the other way around - it was me arguing that animations should win in all cases. I still believe this and I have an ACTION to email www-style to justify it.

Dean

> 
> For the small subset of users that do want this behavior, it would be easier to create another <div> and let the transition or animation apply to that. (This would also indicate the order)
> 
> Rik
> 
> On Thu, Nov 1, 2012 at 2:22 PM, Shane Stephens <shans@google.com> wrote:
> 
> 
> 
> 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
> 
>