184522 - positioned elements do not display properly when zIndex set through JavaScript function (ATTN: see addn.info below first)

Status: RESOLVED INVALID

(Core :: Web Painting, defect)

Description

[Bob Boyle]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021104 Chimera/0.6
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2) Gecko/20021126

Check the test page at the URL for a fairly barebones example. The JS function
used moves a div to the top of the stack when it is clicked by (1) setting the
previous top div's zIndex to 0 and (2) setting the clicked div's zIndex to 100
(it's a test case for my students, so I'm being a little extreme with the values
;^). Issue is this: when two overlapping elements have the same zIndex, the one
appearing last in the code should be on top. Problem is that once all the
"boxes" on the test page have been clicked, box1 should always be on the very
bottom if it is not on the top. Similarly, if box1 is on the top, box2 should
always be under box3. Box3 should never be on the bottom.

Same issue appears in Chimera 0.6 and Netscape7 on Win2k. Testing in IE5+ on Mac
and Win has shown what I understand to be the standards-compliant behavior as
described above.

Reproducible: Always

Steps to Reproduce:
1. Click box2 (box2 zIndex set to 100, others not affected)
2. Click box3 (box2 zIndex set to 0, box3 to 100)
3. Click box1.(box3 zIndex set to 0, box1 to 100, box2 untouched at 0. At this
point, each box has had its zIndex set by the function used on this page.)
4. Click box2. Issue occurs at this point.

Actual Results:  
In step 4, box2 comes to the top of the stack with its zIndex set to 100. Box1
has zIndex set to 0. Box3, from step 3, also has zIndex of 0. Given their order
of appearance in the code, box3 should be on top of box1.

Expected Results:  
Excuse me ... I just read the standards ... see additional information box (but
I'm not retyping what I entered above ;^)

My mistake. Just checked the standards and verified with Eric Meyer's CSS2
reference (Osborne ISBN 0-07-213178-0). This is not a request for a new feature,
but a pat on the back for what's already there.

Apparently, elements with the same zIndex have a relative value of "auto", and
the standards make no mention of how the stacking order should be resolved in
such a case. IE always renders as described above: elements with equal zIndicies
draw with the last rendered at the top of the stack.

I just tried a local page with the zIndex of all three initially set to 1. As
with IE, Mozilla renders them "last on top, first on bottom." Once you get into
clicking the boxes, though, the box that used to be on top gets moved
immediately underneath the clicked box, which is now on top.

Quite frankly, I'm glad the standards didn't specify that behavior as I think
your interpretation is a better solution. In a sense, the function creates a
"stacking context" of just the formerly-top-box and the new-top-box, ignoring
the other element on the page, rather than reshuffling the entire deck. Imagine
if there were four or five or fifty boxes -- that reshuffle process would eat
too much processor time for what its worth, and it would look a bit unnatural.

All in all -- looks like a winner here, folks. Great job!

I thought I should submit this anyway since I've seen the "IE Way" or
interpretation of this resolution for elements with the same zIndex stated as if
it were the standard. It isn't. Just wanted to raise your awareness in case
someone else with some esoteric JS zIndex issue brings it up without doing the
homework ... you shouldn't have to either. Cheers.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Actually, the standard pretty clearly says that elements with equal z-index are
painted in document order (see http://www.w3.org/TR/CSS21/visuren.html#q29
paragraph 3, last sentence).

Over to views... roc, I suspect you have bugs on this already, no?

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yeah. We don't enforce the document order when we should.

Comment 3

[Bob Boyle]

That's what I get for listening to what Eric Meyer has to say, instead of
reading the standards more carefully ;^). I still think the way gecko handles it
now looks better and makes more sense. Not being part of this resolution-of-bugs
process on a regular basis, how do you handle what may be interpreted as a
conflict between a page as initially rendered and one whose appearance is
modified when JS alters some DOM property?

I mean, is it a valid argument that in such a case, when a JS function is
adjusting the zIndex of two elements, that this creates its own stacking
context? Am I splitting hairs too finely here?

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We do not consider the "history" of a document when we render it (except for
certain buggy situations, such as one you may have found here). We are supposed
to depend only on the state of the DOM (and its associated style data). It's
ultimately a lot simpler that way for the author, and ultimately for us too.

Comment 5

[Eric A. Meyer (dead account)]

Yeah, I'm wrong about this stuff from time to time.  I would try a convoluted
argument as to why my book text could be considered to be correct in a certain
interpretive way, but that would just be weaseling.  I got it wrong there; I was
probably thinking about browser behavior too much and not reading the spec
closely enough.  Mea culpa.

Comment 6

[Kevin Berkheiser]

The URL is no longer good.  Reporter, could you provide a new example?

Comment 7

[Bob Boyle]

http://nsu.primesix.com/examples/dhtml/basics/pos-el-z.html

Comment 8

[Gabriel Sjoberg]

Original reporter has rescinded the bug report.  Marking INVALID.