Re: [will-change] Should will-change trigger stacking context when the property does not apply to an element?

> On Aug 16, 2015, at 1:20 pm, L. David Baron <> wrote:
> On Sunday 2015-08-16 12:22 -0700, Simon Fraser wrote:
>>> On Aug 16, 2015, at 12:17 pm, Simon Fraser <> wrote:
>>> Consider:
>>> <span style=“will-change: transform;”>...<span>
>>> The span, as a non-atomic inline, does not support the transform property. Should will-change trigger stacking context in this example?
>> A more compelling testcase is:
>> <div style=“will-change: z-index;"></div>
>> z-index only applies to positioned elements so does “will-change:z-index” alone create stacking context? If no, does this:
>> <div style=“will-change: position, z-index;"></div>?
> Without having an opinion on whether it *should*, I'll comment that
> Gecko currently causes the stacking context behavior when
> will-change has any properties in a list of properties that can
> cause stacking contexts, without considering whether they currently
> apply.  (Our current list is clip-path, filter, isolation, mask,
> mix-blend-mode, perspective, position, transform, transform-style,
> and z-index; in the code this is the bit

Comparing with WebKit’s list, I think you’re missing opacity.

During testing, I also noticed that Firefox treats “will-change: will-change;” as valid, which the spec says it should not.

As to the original question, I would like to prevent:

* { will-change: transform; }

from making all inlines be stacking contexts (which causes WebKit to
allocate additional data structures). So I would prefer we spec it such that
will-change creates stacking context only if the specified properties actually
apply to the element.

However, that raises the point that you could say
* { will-change: display, transform; }
and then transform may have an effect at some point later when display:block is applied,
which is then essentially the same as the position/z-index example.


Received on Sunday, 16 August 2015 21:09:13 UTC