Csswg-drafts: [css3-positioning] position:sticky should create a stacking context

Created on 22 Feb 2017  路  8Comments  路  Source: w3c/csswg-drafts

I think position:sticky should create a stacking context, as we have resolved to do for position:fixed.

css-position-3

All 8 comments

+1

I've hit this in practice today and have no workaround

as we have resolved to do for position:fixed

Does this mean position: fixed will start creating a stacking context even without the use of z-index? Is that in the current working draft?

@keithjgrant The working group resolved to have position:fixed create a stacking context in their 2015-07-01 meeting. While it was left out of subsequent spec revisions on accident, it was added in on 2016-11-18.

See https://github.com/w3c/csswg-drafts/issues/451#issuecomment-261457816 for more info.

tl;dr Yes, position:fixed already creates a stacking context even without the use of z-index.

I believe that @tabatkins's reasoning in the related issue and the fact that Edge managed to implement position:sticky without necessarily making it stacking context are good argument _against_ making this change in the spec. The position:fixed special case was introduced rather ad hoc, mostly to match the already long existed implementation that was too hard to "fix", but I hope the position:sticky case is different and we can do better this time.

@smfr, could you please clarify what is the most difficult problem of implementing position:sticky without making it stacking context for z-index: auto?

@smfr Any new thoughts on this before adoption makes it too late and interop causes standards to resolve on a possibly subpar decision? Especially since @tabatkins and @FremyCompany weighed in on current language sufficing? Even more important while https://github.com/w3c/csswg-drafts/issues/2717 is consolidating how/if stacking contexts automatically sort in z space?

Chromium already treats both position: fixed and position: sticky as stacking contexts.
See here.

The reason that such elements are stacking contexts is that they need to move with respect to scroll, and in particular composited scrolling layers. Therefore they are put in their own composited layer, and
if that layer were not a stacking context, then a lot of unnecessary implementation complexity
would result due to the contents of the fixed/sticky subtree not being atomically rendered.

I think the next step is to file an issue with edge and create wpt tests. And edit the spec to agree with behavior on the other browsers.

Edge no longer exists as a different browser. The spec needs to be edited to make position:sticky a stacking context and a WPT test added. @tabatkins

Was this page helpful?
0 / 5 - 0 ratings