- From: <lists@m8y.org>
- Date: Tue, 5 Feb 2013 13:24:38 -0500 (EST)
- To: www-style@w3.org
On Tue, 5 Feb 2013, Simon Fraser wrote: > On Feb 5, 2013, at 10:48 AM, lists@m8y.org wrote: > >> On Tue, 5 Feb 2013, Simon Fraser wrote: >> >>> On Feb 5, 2013, at 9:04 AM, lists@m8y.org wrote: >>> >>>> So. http://m8y.org/tmp/chrome_wtf.xhtml >>>> Is a mockup of a problem I encountered recently. >>>> >>>> I was told to bring this up here. >>>> How does Chrome expect us to workaround this behaviour? Or are we just not supposed to implement layouts like this anymore? >>> >>> What is the exact problem that you're seeing? How does Chrome's behavior differ from other browsers? >> >> Appears to be related to: >> http://updates.html5rocks.com/2012/09/Stacking-Changes-Coming-to-position-fixed-elements >> >> The page has instructions to reproduce on it, did you try them? I can take screenshots if that helps. > > Indeed. WebKit creates stacking context for position:fixed, in order to optimize scrolling. This is not strictly compatible with the spec, but was thought to have minimal real-world impact. Real world is a relative thing I guess. When IE controlled the web, one could say IE6 not supporting position:fixed at all had little real-world impact 'cause we had no choice. Certainly, I don't see a way to do the layout on that page anymore. It seems to me if one is deliberately breaking the spec such that position no longer works right, it'd be nice to offer -webkit-position so we could target the broken implementation w/o javascript. Man. Maybe there needs to be a generic spec for the equivalent of IE condcoms :) Then I could just target the UA.
Received on Tuesday, 5 February 2013 18:25:00 UTC