:: Developer Documentation Request Request Type: Correction Gecko Version: unspecified Technical Contact: :: Details The live sample div boxes displayed on the page don't match the example source code beneath, and don't follow the stacking rules described. The positioned DIV#1 box should appear in front of the floated DIV#3 box, not behind it. I've tested the example source code in Firefox and Chrome by copying it into a new html file, and it shows DIV#1 in front as expected, so I'm pretty sure the problem must be in the live sample. Also, "Open in CodePen" and "Open in JSFiddle" aren't working properly on this page: when they open the CSS code is missing, only the HTML code shows up.
(In reply to timtylor from comment #0) > :: Developer Documentation Request > > Request Type: Correction > Gecko Version: unspecified > Technical Contact: > > :: Details > > The live sample div boxes displayed on the page don't match the example > source code beneath, and don't follow the stacking rules described. The > positioned DIV#1 box should appear in front of the floated DIV#3 box, not > behind it. I've tested the example source code in Firefox and Chrome by > copying it into a new html file, and it shows DIV#1 in front as expected, so > I'm pretty sure the problem must be in the live sample. Also, "Open in > CodePen" and "Open in JSFiddle" aren't working properly on this page: when > they open the CSS code is missing, only the HTML code shows up. Hi there, I've had a look at this, and it looks like the sample displays as expected for me (I took a copy of the code shown in the article like you did, then tried loading it in Firefox/Chrome). The description says that descendant blocks in the normal flow should appear behind floated and positioned blocks, which is what is happening. 4 is appearing behind all the others. It then says that descendant positioned elements should appear in front of floated blocks, which is also happening. 1 and 5 are appearing on front of 2 and 3. The live example must be matching the source code, and the source code is feeding into the live example. Oh, wait, there is one thing wrong! In the rendering on MDN, 1 is showing BEHIND 3, which is not correct. Let me explore this and get back to you.
Assignee: nobody → cmills
Hrm, yes, it looks like the description is wrong in the page. It looks like floats and positioned elements have the same stacking context as each other, so the stacking order is based just on source order for all of them. I'm calling in an engineer to help. Daniel, I am investigating the following page: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Positioning/Understanding_z_index/Stacking_and_float The stacking order descriptions look wrong, as box 1 is behind box 2; according to the description, it should be in front of it. As I missing something, or do we need to update the description? Have these rules changes in the last couple of years? Thanks in advance.
(In reply to Chris Mills (Mozilla, MDN editor) [:cmills] from comment #2) > Hrm, yes, it looks like the description is wrong in the page. It looks like > floats and positioned elements have the same stacking context as each other, > so the stacking order is based just on source order for all of them. So, "opacity" does make each of these elements generate their own stacking context: # "implementations must create a new stacking context for any element with opacity less than 1" https://www.w3.org/TR/css3-color/#transparency ...and that changes things. (More on this below.) In the ABSENCE of "opacity", your initial expectation (that abspos elements should go in front of floats) is correct, and we do actually match that expectation if you remove "opacity". The spec text on this is here: https://www.w3.org/TR/CSS22/zindex.html#painting-order ...and it clearly gives this ordering (back-to-front): # The painting order for the descendants of an element generating a stacking context [...] is: # [...] # 5. All non-positioned floating descendants [...] # [...] # 8. All positioned descendants with 'z-index: auto' or 'z-index: 0', in tree order And indeed, if use devtools to remove "opacity" from the two elements you're asking about, then the abspos one jumps in front. (So how does "opacity" mess things up? It looks like it comes from this chunk of spec-text, also from the spec text linked above: "If an element with opacity less than 1 is not positioned" [this includes the float in your demo] "implementations must paint the layer it creates, within its parent stacking context, at the same stacking order that would be used if it were a positioned element with ‘z-index: 0’ and ‘opacity: 1’." So basically, opacity:[less-than-1] elements get treated as if they were positioned, for the purposes of painting order.) So, bottom-line: we probably want to get rid of the opacity in this example (which makes it match the expectations), unless we're explicitly trying to show this special weird "opacity" behavior (but it doesn't seem like that's what we're trying to highlight).
Flags: needinfo?(dholbert) → needinfo?(cmills)
(In reply to Daniel Holbert [:dholbert] from comment #3) > So, bottom-line: we probably want to get rid of the opacity in this example > (which makes it match the expectations), (To clarify: here I meant "that suggested change would make it match the expectations".)
Thanks for all the explanation Daniel. I didn't know that opacity affected stacking context ... I do now ;-) So, I think you are right - it is not really relevant in this context, and just generates confusion. I've removed it from the example.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.