[css-will-change] Should `will-change: z-index` always create a stacking context even when element is ineligible for z-index?

[nt1m]

If any non-initial value of a property would create a stacking context on the element, specifying that property in will-change must create a stacking context on the element.

This wording is quite ambiguous and does not specify the cases where z-index is not eligible.

Chromium appears to have changed its behavior recently: https://chromium-review.googlesource.com/c/chromium/src/+/7663578

cc @bfgeek @smfr

[bfgeek]

We were basically fixing the test added in servo/servo#35947

We now only create a stacking context if the element is eligible, (this is specified in other specifications).

(e.g. z-index is eligible if the element is positioned (not static), or if it is a flex/grid/etc item as per https://drafts.csswg.org/css-flexbox-2/#painting ).

cc/ @Loirooriol @tabatkins

[smfr]

this is specified in other specifications

I think we still need clarity in cases like:

div {
  position: absolute;
  will-change: z-index:
}

or

div {
  will-change: position, z-index;
}

[tabatkins]

Yes, I believe the reading from the Servo devs was the intention, but I can see how the spec is a bit ambiguous there.

So,

div {
 position: static;
 will-change: z-index; 
  /* does nothing, z-index doesn't apply */
}

and

div {
  position: absolute;
  will-change: z-index; 
  /* creates a stacking context, because some non-initial values of z-index do so */
}

It was definitely not the intention that we do cross-property analysis like in Simon's last example tho:

div {
  position: static;
  will-change: position, z-index; 
  /* does nothing: z-index doesn't currently apply, and position never creates a stacking context
     their combo is irrelevant here */
}

[Loirooriol]

I filed #11827 about this.

I didn't consider Simon's combination, I guess it could make sense to establish a stacking context, but slightly complicates the logic