Hacker News new | ask | show | jobs
by magicalist 5011 days ago
for position: fixed and changed stacking contexts, you're likely running into this:

http://updates.html5rocks.com/2012/09/Stacking-Changes-Comin...

Basically, the position: fixed on the parent of the span you're trying to put on top is now making the parent its own stacking context, which means that all children will be stacked relative to each other, not to the first absolutely or relatively positioned ancestor of the parent, as it was before.

The easiest fix is to set the z-index on the parent, since that will correctly stack it relative to its sibling (your other position: fixed element). The other way is to give the sibling that you want to be below the other content a negative z-index, since that will, again, specify it in the stacking context you want to affect. Both of these fixes should render correctly in older browsers (I believe).

This is annoying when it affects existing content, but it is part of the spec now (and it's apparently how mobile browsers have always rendered it).

3 comments

How much content does this break? Was this discussed on one of the public mailing lists? If so, does anyone have a link to some relevant discussion? (I would love to hear the various positions regarding breaking existing content to bring an optimization used by browsers people generally consider to render things weirdly to all browsers.)
This was proposed here on the CSS WG public mailing list: http://lists.w3.org/Archives/Public/www-style/2012May/0473.h...
Yes, and no one other than WebKit folks seemed to feel it was particularly warranted. Which makes this deliberate spec violation all the more interesting to me. Nothing like sabotaging the standards process by deliberately trying to force the issue in the field when you fail to convince people as part of that process.
The upshot of the discussion was that this change is not needed to optimize things in non-WebKit UAs as far as anyone can tell. So the discussion sort of petered out, last I checked.
for the float issue, I did find this:

http://code.google.com/p/chromium/issues/detail?id=133474

it may be a dupe of an older bug, but I got tired of looking.

It's worth noting that it does not render as stated in Firefox (Mac or Win) or IE9 (in IE9 or compatibility modes).

IE9 puts the entire h1 below the floated content. Firefox is partway between IE and Chrome and moves the "This" off to the right side but puts the rest of the h1 below the floated content. Safari is the only browser that renders like the "old" screenshot with floated content and the h1 overlapping (and I would bet this change was made at the webkit level, so webkit nightly and eventually safari will lay out like chrome).

I avoid floated content whenever possible, so I can't comment on which browser has the correct rendering. That every browser renders differently doesn't speak well for the state of the float spec, though :) It looks like it's the negative top margin of the element after the floated content that is the root of the disagreement, and that particular case may just be under- or unspecified.

What does the spec say? is there a bug opened already? or are all the browsers wrong and Chrome is right?
The spec says Chrome is right (was recently changed). Chrome is not the only browser. iOS browsers, the Android browser and Chrome for Android have always used the new behavior. The reason for the change is faster scroll performance, particularly on mobile.
Really? Can you point to the spec change? Did I miss a working group decision on this somewhere? Last I checked, the discussion on this got nowhere, with WebKit folks claiming this change was needed to optimize stuff and Opera and Mozilla folks claiming that optimizing scrolling worked just fine without this behavior change...
This has no such change. Try again.
Those are all webkit based browsers, so it seems normal that they'd all behave the same.
Well they did not. Until Chrome changed the behavior to comply with http://www.w3.org/TR/CSS21/zindex.html
The CSS 2.1 spec was last updated in 2011 and does not include any mention of this new stacking context behavior (which was only proposed on the CSS mailing list in May 2012 and has not yet made it into any spec).
No, they changed it to no longer comply with that spec, actually. Please do read the spec, not assume it says what the "html5rocks" marketing folks want it to say.