Re: [css3-animations] Establishing stacking context at animation start

On 2016/05/05 5:06, Simon Fraser wrote:
>> On Apr 27, 2016, at 5:48 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>
>> On Wed, Apr 27, 2016 at 5:02 PM, Brian Birtles <bbirtles@mozilla.com> wrote:
>>> On 2016/04/28 8:23, Tab Atkins Jr. wrote:
>>>>
>>>> On Wed, Apr 27, 2016 at 4:16 PM, Brian Birtles <bbirtles@mozilla.com>
>>>> wrote:
>>>>>
>>>>> On 2016/04/27 13:49, Brian Birtles wrote:
>>>>>>
>>>>>> I've noticed that IE and Edge appear to do this already.[2] Their
>>>>>> behavior also differs in the test case Simon provided.[3]
>>>>>>
>>>>>> Since IE and Edge already do this, WebKit seems interested, and it would
>>>>>> seem to provide performance advantages, any chance we could revisit
>>>>>> this?
>>>>>
>>>>>
>>>>> I should also mention that CSS Transitions create a stacking context
>>>>> during
>>>>> the delay phase in at least Blink, Gecko, Edge, and IE.
>>>>
>>>>
>>>> Sigh, all right.  In that case, let's specify that, when an
>>>> animation/transition is active, the UA must act as if 'will-change'
>>>> additionally includes all the properties involved.  That answers all
>>>> the questions about how this should act, since it's already been
>>>> answered once.
>>>
>>> That suits me with the clarification that "active" excludes animations that
>>> have finished and are not filling forwards.
>>
>> Yeah, by "active" I meant "running or filling".
>
> This sounds good to me.

Just to check we're on the same page here--this *does* include 
animations in their delay phase *without* a backwards fill, right? I 
updated the spec last week[1] to say that since:

* It's consistent with what transitions do
* It's what Edge does
* It's needed to solve the frame-based animation use case I presented
* It's more consistent with the name 'will-change'

[1] 
https://github.com/w3c/csswg-drafts/commit/d107d5e7b14fd944378da5664394380537b088f3

Received on Friday, 6 May 2016 02:06:49 UTC