11 ms·

What No One Told You About Z-Index

282 points by philipwalton 14y ago

taylorfausak 14y ago
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-order between pieces of content inside of it. [1]: http://www.w3.org/TR/CSS2/visuren.html#z-index http://www.w3.org/TR/CSS2/visuren.html#z-index [2]: http://www.w3.org/TR/2010/PR-css3-color-20101028/#transparency http://www.w3.org/TR/2010/PR-css3-color-20101028/#transparen...
- pattern 14y ago
  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!
  - Hansi 14y ago
    Agree, I remember that it took me a while to figure this out when I first tried playing with z-indexes.
faramarz 14y ago
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 http://codepen.io/anon/pen/DlyAv
- bunkat 14y ago
  This is what I did as well. Seems to make more sense to me than putting an odd opacity value on an element.
- taeric 14y ago
  The point was that you can "alter the z-index" without actually altering the z-index. At least, that was my takeaway.
- dazmax 14y ago
  The point of the example was to show how something other than z-index, position, and order can affect stacking. It wasn't demonstrating the correct way to go about changing the stacking order.
- Argorak 14y ago
  The point was to illustrate the stacking behaviour introduced by opacity, not how to trivially arrange 3 elements using z-index.
- philipwalton 14y ago
  The point was that there are factors other than z-index involved in determining the stacking order. I'm certainly not suggesting anyone use opacity to move things around in the stacking order. I was just trying to make people aware of it. It's confusing if you don't know what's going on.
- khwang 14y ago
  The point of this exercise was to show that opacity has an effect on element position, which was surprising to me! It matters because it might fix a z-index bug you have one day (:
- aroman 14y ago
  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 <span> element stack behind the blue and green <span> 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 element. Do not add/change the position property of any element."
garand 14y ago
To solve the issue of z-index only working on positioned elements, what I do on all new projects is set the following: * { position:relative; } This does two things. Allows me to set z-index values without hassle, and also allows me to set top/bottom left/right values. Refer to my GitHub repo for the code for my base structure for new projects. https://github.com/garand/base https://github.com/garand/base
- crescentfresh 14y ago
  Do you use tables at all? What effect does this have on cells, rows, etc?
  - garand 14y ago
    I haven't worked with tables and this much, so I can't speak for that.
- crazygringo 14y ago
  I've learned never to add rules to the asterisk ever, after being badly burned on other projects multiple times. At first glance, this rule appears more innocuous than others I've seen, because position is never inherited. (Unlike a font-size in a plug-in that broke every inherited font-size on the whole site). But extra position:relative declarations can cause big problems on mobile browsers (including iOS6) when combined with CSS transitions. Don't ask me why, just browser bugs. I'd be extremely wary of any kind of global layout-fixes like this.
- ricardobeat 14y ago
  This does _three_ things: third is severely slows down page rendering.
  - harlanlewis 14y ago
    I can't find any information about `position:relative` impacting page render performance. Please share. Given my experience of low impact on render performance of vanilla properties like this (transitions are a whole 'nother story), I'm much more concerned with whether this is of benefit to developer happiness. You'll never be able to use `position:absolute` for anything outside of the context of an element's parent, and opting out of this back to default behavior is much more painful than opting in with a better-scoped `.feature * {position:relative}`. Every new developer will need to wrap their head around nonstandard page flow, and customizations like this have a way of accumulating into a very intimidating environment. As a general rule, I don't want to inherit anything silent and clever without very compelling reasons (* {box-sizing:border-box} passes this test because it makes so many things so much easier).
flexxaeon 14y ago
(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/#transparency http://www.w3.org/TR/css3-color/#transparency
- ricardobeat 14y ago
  That's the underlying reason - the same is true for position, if they didn't create new contexts rendering would be an impossible mess. Adding opacity to the span has no effect because it already has position:absolute.
- seanalltogether 14y ago
  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.
RyanZAG 14y ago
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.
- mikegirouard 14y ago
  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 < 1 opacity, something different needs to occur to properly render that element. For an opacity of .99, not much visually, but if the opacity is .5 how will it know what elements to display under the partially opaque item? I'd be curious to see some source code to know for sure, but that's my best guess.
  - michielvoo 14y ago
    Here is the explanation: http://www.w3.org/TR/2010/PR-css3-color-20101028/#transparency http://www.w3.org/TR/2010/PR-css3-color-20101028/#transparen... The CSS3 spec describes that the element with opacity < 1 should be composited off screen. Therefor, an element with opacity < 1 must create a stacking context, because its content layers cannot 'intertwine' with other layers not inside the element. Let's say you'd have a rule that pokes a hole in a layer. If that layer contains several pieces of paper, then the spec would say to take the layer with those pieces of paper aside, poke a hole though all of them, then place the layer back where you found it. This way, other layers on the page are not damaged. /end analogy.
ricardobeat 14y ago
TL;DR an opacity value < 1 creates a new stacking context.
crazygringo 14y ago
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?
- gfodor 14y ago
  To be fair, all z-indexes are scoped to something, you just assume that "page" is the scope, but the spec presumes otherwise :)
- eropple 14y ago
  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.
- caf 14y ago
  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.
  - cousin_it 14y ago
    That's an interesting rationale, but pages will never be composable as long as CSS is cascading.
    - Someone 14y ago
grecy 14y ago
Also, don't expect Z-Index to work in IE6 with <select>. It's broken
- rorrr 14y ago
  Anybody still supports IE6? I forgot it like a bad dream.
  - grecy 14y ago
    I'm sitting here on XP developing solely for IE6. It is a bad dream.
    - roel_v 14y ago
      Look at it from the bright side: at least you have a stable target ;)
eranation 14y ago
Don't we love CSS? it's so easy to do both complex things like 3D animations but also simple things like position something centered horizontally or vertically by just saying align:center, oh, sorry, it's margin: 0 auto, right, no? it's left:50% with a relative inside an absolute div, or was that an absolute div inside a relative span? ok so doing it vertically is really easy, it's valign:middle, oh, wait, I'm confusing yucky table layout, it's much simpler, it's, ehm, line-height or something, or vertical-align, but only for text, sorry, silly of me, I just do top:50 and the relative inside absolute trick again (or vice versa, one sec let me check in JSFiddle), Ok aligning might not be a good example, but it's so easy to have something snap to something else, like this DIV top right corner should always be on the buttom left of that other div, oh, can't do without some jQuery code? of course you can, let me go to codepen and show you for a sec, ok, never mind that, at least it's so easy to columns (more than exactly 3) that one of them is fixed width and the others are variable width, that's why we have float:left, float:right and well, nevermind. But I can have a left navigation bar that will stretch to the bottom, or have a footer that will stay down when resizing, it's all easy and done without any workarounds or tricks or endless trips to stackoverflow or using zurb foundation / bootstrap. So I'm surprised that a simple thing like putting something on top of the other got to be so complicated, well, you can't have it all, nothing is perfect </rant>
- moultano 14y ago
  Does anyone have any insight as to why it is this way? To me it seems insane, but I don't trust my own judgement in domains like this because I've never built anything comparable. Are there really good reasons for CSS to be the way it is?
  - 2468ben 14y ago
    (I don't think they're good reasons, just reasons) 1. Unlike print layout, the dimensions of a webpage can change, and so we slowly invented an evolving layout framework for something without fixed dimensions. I've done typesetting since it was exacto knives and hot wax, and if you told me then to imagine a stretchable paper for news I would have cried in the corner. 2. The layout framework was independently built by a bunch of separate companies, who by nature of competition weren't going to agree on everything (see every browser). 3. The agreements that WERE made were done by committee, including the reluctant inputs of competing companies. This method of design will guarantee that they end up with something weird. 4. Make it backwards compatible with all the previous ghosts of architects past. Imagine if Ford, GM and Chrysler had to build a joint car every few years. Also, try designing a page in Flash and using (or just reading about) their graphics/layout/text frameworks. Some things are much harder than HTML/CSS, some are much easier, but it offers a great comparison on a completely different way of solving layout. I've implemented a spec like CSS for customizing Flash app appearances, and compared to what existed before, it made everything better.
baby 14y ago
Long text for just a few explanation. As a developer I hate reading those kind of tips since it doesn't go straight to the point. Here's my tl;dr : > the stacking order is the same as the order of appearance in the HTML Actually this is false, as last in code is displayed on top > When you introduce the position property into the mix, any positioned elements (and their children) are displayed in front of any non-positioned elements Use a "position:" and it will go on top of div not using it. > z-index only works on positioned elements use "position:" to use "z-index" otherwise it won't work. > ... I felt like the rest was unnecessary unless you plan to play a lot with z-index. Then you can get a better tutorial/article/documentation on it.
- the_gipsy 14y ago
  11 paragraphs + code snippets just to say: "opacity" creates a stacking context. And a really annoying way of teasing and dragging the "observation" until the end of the article.
- thiagobrandam 14y ago
  > Actually this is false, as last in code is displayed on top If it's a stack, then the last one _is_ displayed on top.
  - baby 14y ago
    That goes without saying.
archagon 14y ago
I've always wanted to get into web design, but every time I read an article like this, I get scared. Sometimes it seems like the web is nothing but hacks piled on top of hacks...
Fletch137 14y ago
If the model were to stay the same, I'd like to see something like stacking-context:break to start a new stacking context with the targeted element as parent, stacking-context:inherit for children. Same as we have now, but with the option for manual control.
rralian 14y ago
This article should really be titled "What No One Told You About Opacity". I think all the z-index stuff is pretty well-understood. At least by people who consider themselves pretty good at css.

282 points by philipwalton 14y ago

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-order between pieces of content inside of it. [1]: http://www.w3.org/TR/CSS2/visuren.html#z-index http://www.w3.org/TR/CSS2/visuren.html#z-index [2]: http://www.w3.org/TR/2010/PR-css3-color-20101028/#transparency http://www.w3.org/TR/2010/PR-css3-color-20101028/#transparen...

pattern 14y ago
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!
- Hansi 14y ago
  Agree, I remember that it took me a while to figure this out when I first tried playing with z-indexes.

faramarz 14y ago

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 http://codepen.io/anon/pen/DlyAv

bunkat 14y ago
This is what I did as well. Seems to make more sense to me than putting an odd opacity value on an element.
taeric 14y ago
The point was that you can "alter the z-index" without actually altering the z-index. At least, that was my takeaway.
dazmax 14y ago
The point of the example was to show how something other than z-index, position, and order can affect stacking. It wasn't demonstrating the correct way to go about changing the stacking order.
Argorak 14y ago
The point was to illustrate the stacking behaviour introduced by opacity, not how to trivially arrange 3 elements using z-index.
philipwalton 14y ago
The point was that there are factors other than z-index involved in determining the stacking order. I'm certainly not suggesting anyone use opacity to move things around in the stacking order. I was just trying to make people aware of it. It's confusing if you don't know what's going on.
khwang 14y ago
The point of this exercise was to show that opacity has an effect on element position, which was surprising to me! It matters because it might fix a z-index bug you have one day (:
aroman 14y ago
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 <span> element stack behind the blue and green <span> 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 element. Do not add/change the position property of any element."

garand 14y ago

To solve the issue of z-index only working on positioned elements, what I do on all new projects is set the following: * { position:relative; } This does two things. Allows me to set z-index values without hassle, and also allows me to set top/bottom left/right values. Refer to my GitHub repo for the code for my base structure for new projects. https://github.com/garand/base https://github.com/garand/base

crescentfresh 14y ago
Do you use tables at all? What effect does this have on cells, rows, etc?
- garand 14y ago
  I haven't worked with tables and this much, so I can't speak for that.
crazygringo 14y ago
I've learned never to add rules to the asterisk ever, after being badly burned on other projects multiple times. At first glance, this rule appears more innocuous than others I've seen, because position is never inherited. (Unlike a font-size in a plug-in that broke every inherited font-size on the whole site). But extra position:relative declarations can cause big problems on mobile browsers (including iOS6) when combined with CSS transitions. Don't ask me why, just browser bugs. I'd be extremely wary of any kind of global layout-fixes like this.
ricardobeat 14y ago
This does _three_ things: third is severely slows down page rendering.
- harlanlewis 14y ago
  I can't find any information about `position:relative` impacting page render performance. Please share. Given my experience of low impact on render performance of vanilla properties like this (transitions are a whole 'nother story), I'm much more concerned with whether this is of benefit to developer happiness. You'll never be able to use `position:absolute` for anything outside of the context of an element's parent, and opting out of this back to default behavior is much more painful than opting in with a better-scoped `.feature * {position:relative}`. Every new developer will need to wrap their head around nonstandard page flow, and customizations like this have a way of accumulating into a very intimidating environment. As a general rule, I don't want to inherit anything silent and clever without very compelling reasons (* {box-sizing:border-box} passes this test because it makes so many things so much easier).

flexxaeon 14y ago

(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/#transparency http://www.w3.org/TR/css3-color/#transparency

ricardobeat 14y ago
That's the underlying reason - the same is true for position, if they didn't create new contexts rendering would be an impossible mess. Adding opacity to the span has no effect because it already has position:absolute.
seanalltogether 14y ago
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.

RyanZAG 14y ago

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.

mikegirouard 14y ago
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 < 1 opacity, something different needs to occur to properly render that element. For an opacity of .99, not much visually, but if the opacity is .5 how will it know what elements to display under the partially opaque item? I'd be curious to see some source code to know for sure, but that's my best guess.
- michielvoo 14y ago
  Here is the explanation: http://www.w3.org/TR/2010/PR-css3-color-20101028/#transparency http://www.w3.org/TR/2010/PR-css3-color-20101028/#transparen... The CSS3 spec describes that the element with opacity < 1 should be composited off screen. Therefor, an element with opacity < 1 must create a stacking context, because its content layers cannot 'intertwine' with other layers not inside the element. Let's say you'd have a rule that pokes a hole in a layer. If that layer contains several pieces of paper, then the spec would say to take the layer with those pieces of paper aside, poke a hole though all of them, then place the layer back where you found it. This way, other layers on the page are not damaged. /end analogy.

ricardobeat 14y ago

TL;DR an opacity value < 1 creates a new stacking context.

crazygringo 14y ago

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?

gfodor 14y ago
To be fair, all z-indexes are scoped to something, you just assume that "page" is the scope, but the spec presumes otherwise :)
eropple 14y ago
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.
caf 14y ago
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.
- cousin_it 14y ago
  That's an interesting rationale, but pages will never be composable as long as CSS is cascading.
  - Someone 14y ago

grecy 14y ago

Also, don't expect Z-Index to work in IE6 with <select>. It's broken

rorrr 14y ago
Anybody still supports IE6? I forgot it like a bad dream.
- grecy 14y ago
  I'm sitting here on XP developing solely for IE6. It is a bad dream.
  - roel_v 14y ago
    Look at it from the bright side: at least you have a stable target ;)

eranation 14y ago

Don't we love CSS? it's so easy to do both complex things like 3D animations but also simple things like position something centered horizontally or vertically by just saying align:center, oh, sorry, it's margin: 0 auto, right, no? it's left:50% with a relative inside an absolute div, or was that an absolute div inside a relative span? ok so doing it vertically is really easy, it's valign:middle, oh, wait, I'm confusing yucky table layout, it's much simpler, it's, ehm, line-height or something, or vertical-align, but only for text, sorry, silly of me, I just do top:50 and the relative inside absolute trick again (or vice versa, one sec let me check in JSFiddle), Ok aligning might not be a good example, but it's so easy to have something snap to something else, like this DIV top right corner should always be on the buttom left of that other div, oh, can't do without some jQuery code? of course you can, let me go to codepen and show you for a sec, ok, never mind that, at least it's so easy to columns (more than exactly 3) that one of them is fixed width and the others are variable width, that's why we have float:left, float:right and well, nevermind. But I can have a left navigation bar that will stretch to the bottom, or have a footer that will stay down when resizing, it's all easy and done without any workarounds or tricks or endless trips to stackoverflow or using zurb foundation / bootstrap. So I'm surprised that a simple thing like putting something on top of the other got to be so complicated, well, you can't have it all, nothing is perfect </rant>

moultano 14y ago
Does anyone have any insight as to why it is this way? To me it seems insane, but I don't trust my own judgement in domains like this because I've never built anything comparable. Are there really good reasons for CSS to be the way it is?
- 2468ben 14y ago
  (I don't think they're good reasons, just reasons) 1. Unlike print layout, the dimensions of a webpage can change, and so we slowly invented an evolving layout framework for something without fixed dimensions. I've done typesetting since it was exacto knives and hot wax, and if you told me then to imagine a stretchable paper for news I would have cried in the corner. 2. The layout framework was independently built by a bunch of separate companies, who by nature of competition weren't going to agree on everything (see every browser). 3. The agreements that WERE made were done by committee, including the reluctant inputs of competing companies. This method of design will guarantee that they end up with something weird. 4. Make it backwards compatible with all the previous ghosts of architects past. Imagine if Ford, GM and Chrysler had to build a joint car every few years. Also, try designing a page in Flash and using (or just reading about) their graphics/layout/text frameworks. Some things are much harder than HTML/CSS, some are much easier, but it offers a great comparison on a completely different way of solving layout. I've implemented a spec like CSS for customizing Flash app appearances, and compared to what existed before, it made everything better.

baby 14y ago

Long text for just a few explanation. As a developer I hate reading those kind of tips since it doesn't go straight to the point. Here's my tl;dr : > the stacking order is the same as the order of appearance in the HTML Actually this is false, as last in code is displayed on top > When you introduce the position property into the mix, any positioned elements (and their children) are displayed in front of any non-positioned elements Use a "position:" and it will go on top of div not using it. > z-index only works on positioned elements use "position:" to use "z-index" otherwise it won't work. > ... I felt like the rest was unnecessary unless you plan to play a lot with z-index. Then you can get a better tutorial/article/documentation on it.

the_gipsy 14y ago
11 paragraphs + code snippets just to say: "opacity" creates a stacking context. And a really annoying way of teasing and dragging the "observation" until the end of the article.
thiagobrandam 14y ago
> Actually this is false, as last in code is displayed on top If it's a stack, then the last one _is_ displayed on top.
- baby 14y ago
  That goes without saying.

archagon 14y ago

I've always wanted to get into web design, but every time I read an article like this, I get scared. Sometimes it seems like the web is nothing but hacks piled on top of hacks...

Fletch137 14y ago

If the model were to stay the same, I'd like to see something like stacking-context:break to start a new stacking context with the targeted element as parent, stacking-context:inherit for children. Same as we have now, but with the option for manual control.

rralian 14y ago

This article should really be titled "What No One Told You About Opacity". I think all the z-index stuff is pretty well-understood. At least by people who consider themselves pretty good at css.