Managing CSS Stacking Contexts in a "Hostile" Environment

[Thierry]

Originally published at: http://www.sitepoint.com/managing-css-stacking-contexts-hostile-environment/

Note: This is a proposal I recently wrote for Yahoo. It has been edited for an external audience.

The order in which the rendering tree is painted onto the canvas is described in terms of stacking contexts.

Things get complicated when authors are unfamiliar with the stacking contexts of a page or are simply oblivious to their state.

TL:DR; Proposal – Demo

Interactive Advertising Bureau Guidelines for z-index

From the IAB’s perspective, things are pretty straightforward. They have a whole table specifying z-index ranges for almost all types of content, not just ads.

Source: IAB Display Advertising Guidelines

Continue reading this article on SitePoint

[PaulOB]

Interesting and well thought out article Thierry.

z-index has always been a pain to manage (especially in the early days when IE didn’t understand the auto value). It also just became harder now that webkit pulls fixed positioned elements out of their current context (contrary to the specs).

To me it would have made more sense for z-index to be simpler and a higher or lower z-index wins out as required. Atomic stacking contexts often fail because you may want a graphical element of your design overlapping a number of columns yet you will still want a flyout or popup being on top of this no matter where it is and adjusting the z-index of the parent dynamically breaks this layout and indeed things like shadows on the elements/columns will be lost while the dynamic effect takes place.

[Thierry]

Hey, Paul, Thanks

To me it would have made more sense for z-index to be simpler and a higher or lower z-index wins out as required

I’m not sure that would solve the problem though because it would require to know all elements involved in the stack and to also know their position in that stack (as there’d be a single stack). data that I find difficult to gather in a multi-team environment or when dealing with third-party components. Also, since source order plays a role too, the only box we know for sure would be on top of the stack is the one with the highest z-index (upper limit) which is also last in the source code. Not sure in this case authors would have much control. I think the atomic nature at least helps in this regard. It’s far from perfect, but it allows to have some control over how different elements stack on the page, regardless of their own z-index.

As a side note, since you mentioned position:fixed and the specs - the one that bothers me is the fact that fixed works the same as absolute inside elements that are “transformed”.

Thanks for the feedback!

[PaulOB]

@Thierry

As a side note, since you mentioned position:fixed and the specs - the one that bothers me is the fact that fixed works the same as absolute inside elements that are “transformed”.

Yes that one has bitten a few people.

@Thierry

I’m not sure that would solve the problem though because it would require to know all elements involved in the stack and to also know their position in that stack (as there’d be a single stack). data that I find difficult to gather in a multi-team environment or when dealing with third-party components.

True, that would be awkward.

Maybe we needed to have both atomic and non atomic z-index values so we could control individuals or blocks as required. For dynamic elements like flyouts a value like “on-top” would be nice so that it goes on top of everything regardless .