+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 #451 (comment) 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 #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 resolved? Does position: sticky create stacking context in other browsers? I found an issue with position: sticky on a table. That may be related to a problem that position: sticky doesn't create stacking context. The issue is visible in Firefox and Chrome. The z-index is ignored and the actual z-index is taken from the order in HTML, I'm not sure if this manifestation of the fact the it doesn't create stacking context.

Agenda+ to confirm that stickypos should create a stacking context just like fixpos does, for the reasoning given by @chrishtr in #1053 (comment)

We should remember to republish css-position-3 (and css-align-3, which is inter-dependent with its updates) after the CSSWG resolution here, it's the only significant thing blocking republication.

The CSS Working Group just discussed [css3-positioning] position:sticky should create a stacking context, and agreed to the following:

• RESOLVED: stickypos makes a stacking context, just like fixpos