Re: [csswg-drafts] anything that creates a stacking context should sort in the positioned descendants z-ordering list

I am in favor of making a stacking-context-inducing properties result in the element being painted at the same time as positioned elements, mainly for practical and interop reasons. (*)

(One point regarding mask: Chromium does in fact apply paint-as-if-positioned for masks, but mask is still a prefixed property in Chromium (-webkit-mask).)

However, we should also revisit the relation between various kinds of replaced or scrolling content, paint-as-if-positioned, and stacking contexts. Here is some research I have done:

1. <foreignObject>: Edge, Safari, Gecko and Chromium (as of Chromium 67) treat <foreignObject> "as a stacking context", but do *not* paint-as-if-positioned for this element. To support this combination, Chromium recently added code to support the concept of a "replaced normal flow stacking context", which previously was not supported.

2. <video>: Chromium implements video overlay controls underneath user-agent shadow DOM that is a descendant of the <video> element. <video> elements paint-as-if-positioned; therefore the shadow DOM for the controls "inherits" this due to being children. However, video elements are not currently a stacking context or containing block for all descendants. This may end up a problem for custom element-defined
video.

3. <iframe>: iframe elements paint-as-if-positioned in Chromium, WebKit, Gecko and Edge. The iframe contents are painted atomically, but since they are from a different frame the question of stacking context doesn't apply.

4. Scrolling. Chromium and WebKit both paint-as-if-positioned if overflow:scroll is present and there is actual overflow; otherwise they do not paint-as-if-positioned. Until recently, Chromium only applied this quirk for composited scrolling; WebKit may still have this restriction. Neither Gecko nor Edge do this. A long-standing bug in Chromium and WebKit (crbug.com/370604) makes it hard to achieve interop with (4), but Chromium is working towards a fix.

This testpage demonstrates the above examples: http://output.jsbin.com/teyiwiz/15/quiet

(*) In fact, I think a thorough revision and update to this algorithm should be done to incorporate the latest state of actual browsers and spec currently-undefined behavior.


-- 
GitHub Notification of comment by chrishtr
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2717#issuecomment-395911418 using your GitHub account

Received on Friday, 8 June 2018 22:40:53 UTC