Containers & Context
Containers & Context êŽë š
I ran into what I thought was a z-index
bug in Safari (or, Safari had it right and Chrome and Firefox had it wrong). I made a reduced test case here (chriscoyier
).

But itâs not a bug.
Info
Stephanie Eckles let me know about a change to the specs (w3c/csswg-drafts
):
RESOLVED: container-type does not force layout containment, but does force an independent formatting context
This apparently means declaring a container doesnât force a new formatting context anymore and thus my negative z-index
would âworkâ as I wanted it to.
Chrome and Firefox have made the change and it out in the stable version of those browsers. Safariâs update will roll out⊠at some point.
Thatâs an interesting situation isnât it?! It looks and feels like a bug, but really itâs just a situation of a spec change and varied levels of browser support for that change. Itâs not a matter of support-or-no-support of a feature, itâs a side effect. As far as I know, not practically testable. Just something that has to be lived with until all browsers implement it the same.
Itâs a decently beefy change (affecting important stuff like positioning), and almost certainly for the better (because you can still force a formatting context if you want, itâs just nice to have the option). Since I became aware of this, I helped someone else having the same problem. In both cases, we totally aborted what we were trying to do as there didnât seem to be any workaround that felt great. Probably a metaphor in there somewhere.
Despite improved tools over the years (i.e. @supports
and CSS.supports()
) sometimes figuring out browser support is still just hard. Guaranteed I would have been tripped up by Stoyan Stefanovâs issue with @supports and @font-face troubles as well. Good thing we blog, eh?