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

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)

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
>>
>
>