Live data from Hacker News

What No One Told You About Z-Index

philipwalton.com

21–30 of 100 posts

Re: What No One Told You About Z-Index

#21

Serious question: why do stacking contexts exist? They seem to defeat the whole purpose of z-indexes, which is a global way of determining what shows up in front of what else. I'm trying to wrap my head around them -- I guess the main takeaway is, if you don't ever want to have to deal with them, then don't ever use nested elements where both have z-indexes?

A stacking context is analogous to a frame buffer object in OpenGL or a render target in Direct3D. (I'm reasonably sure this is what at least some browsers do for rendering elements with partial opacity.) The difference in opacity (generally) necessitates rendering the content in its own buffer and then rendering it into the viewport.

It's fairly prohibitive to try to correctly break up the differing Z-indexes and do the right thing when rendering, and was probably easier, with no real loss of functionality, to introduce stacking contexts.

Re: What No One Told You About Z-Index

#23
post #15

This seems more like a bug in opacity than anything. Logically, opacity should have no impact at all on layout positioning, only on blending. So this is more of a workaround created to speed up processing of elements with opacity less than 1 that introduces a design bug in the spec.

I'm no expert on the matter, as I just learned about this about 90 seconds ago… but here's my guess:

My understanding of it is that if an element has I'd be curious to see some source code to know for sure, but that's my best guess.

Re: What No One Told You About Z-Index

#24

Serious question: why do stacking contexts exist? They seem to defeat the whole purpose of z-indexes, which is a global way of determining what shows up in front of what else. I'm trying to wrap my head around them -- I guess the main takeaway is, if you don't ever want to have to deal with them, then don't ever use nested elements where both have z-indexes?

It seems to be to make pages more composable - so at the top level you can specify what order block A and B are stacked, and within A and B you can independently specify what order the blocks that make those up are stacked.

This way you can change the relative order of A and B without worrying about how those blocks are internally structured, and whether they use z-index themselves.

Re: What No One Told You About Z-Index

#25

(I'm guessing that) since opacity is a "postprocessing operation"[1] it has to 'redraw' the entire div which causes it to fall back to it's parent order in the stack. But I'm not sure if this is a fair assessment, as you're applying opacity to the div instead of the span.red, the element where the rule was applied. When adding opacity to the span the z-index stays intact [1] http://www.w3.org/TR/css3-color/#transpare…

Which is strange because many other frameworks will end up popping elements with postprocessing effects to the top of the stack, rather then rerender the entire stack.

Re: What No One Told You About Z-Index

#26
post #11
post #3

But I got the same result by assigning z-index 2 and 3 to the other colors. So the results is the same, but the method is incorrect? does it matter? hmm http://codepen.io/anon/pen/DlyAv

I don't really want to add to the dogpile of comments explaining why you missed the point, but the blog post pretty clearly states what the criteria for the "challenge" were: "Here's the challenge: try to see if you can make the red element stack behind the blue and green elements without breaking any of the following rules: Do not alter the HTML markup in any way. Do not add/change the z-index property of any elemen…

He didn't change the markup. He changed the CSS. He didn't add a property to an element. He added a property to a rule.

Re: What No One Told You About Z-Index

#27

Serious question: why do stacking contexts exist? They seem to defeat the whole purpose of z-indexes, which is a global way of determining what shows up in front of what else. I'm trying to wrap my head around them -- I guess the main takeaway is, if you don't ever want to have to deal with them, then don't ever use nested elements where both have z-indexes?

To be fair, all z-indexes are scoped to something, you just assume that "page" is the scope, but the spec presumes otherwise :)

Re: What No One Told You About Z-Index

#28
post #11

Earlier quoted context omitted.

I don't really want to add to the dogpile of comments explaining why you missed the point, but the blog post pretty clearly states what the criteria for the "challenge" were: "Here's the challenge: try to see if you can make the red element stack behind the blue and green elements without breaking any of the following rules: Do not alter the HTML markup in any way. Do not add/change the z-index property of any elemen…

He didn't change the markup. He changed the CSS. He didn't add a property to an element. He added a property to a rule.

He didn't add a property to a rule. He entered text in the CSS editor.

He didn't enter text in the CSS editor. He pressed some buttons on a keyboard.

We could keep at this for a while, if you want.

Re: What No One Told You About Z-Index

#29
post #4

The key takeaway: > New stacking contexts can be formed [… w]hen an element has an > opacity value less than 1. I had no idea that was the case. The CSS 2.1 spec [1] notes that "other properties may introduce stacking contexts, for example 'opacity'". The CSS 3 spec [2] elaborates: > Since an element with opacity less than 1 is composited from a > single offscreen image, content outside of it cannot be layered > in z…

My main takeaway was the following: Z-index only works on positioned elements. If you try to set a z-index on an element with no position specified, it will do nothing. I know I have scratched my head in the past trying to get z-index do what I want, and this knowledge probably would have helped!

Agree, I remember that it took me a while to figure this out when I first tried playing with z-indexes.
Post reply on HN