- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Tue, 5 Feb 2013 13:21:01 -0800
- To: lists@m8y.org
- Cc: www-style@w3.org
On 2/5/13, lists@m8y.org <lists@m8y.org> wrote: > 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. IE6 not supporting position:fixed was a common complaint among web developers. The common workarounds came long before then, and included using javascript to update those elements' positions. -- Garrett Twitter: @xkit personx.tumblr.com
Received on Tuesday, 5 February 2013 21:21:29 UTC