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

I should check the minutes. I *thought* he said that this is how he
implemented it (transitions trump animations) but that it should have been
the other way.
The discussion was intense so I might be wrong :-)

I  would prefer a simple rule as opposed to a complex model.

Rik

On Fri, Nov 9, 2012 at 11:30 AM, Dean Jackson <dino@apple.com> wrote:

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