Re: Proposal: position:fixed elements should form new stacking contexts

I strongly support this change. It will allow browsers to more quickly and efficiently adopt scrolling behaviors that can make use of the GPU for scrolling.

We did discover recently that Google+ is broken if position:fixed creates stacking context, but I suspect that James might be able to get that addressed.

Simon

On May 14, 2012, at 3:51 AM, Kenneth Rohde Christiansen wrote:

> Hi there,
> 
> Recently Yael (cc'ed) implemented fixed position support for Qt based
> [mobile] browsers, and as a result we should now have a feature flag
> in WebKit allowing to always creating a new stacking context. Thus
> this now happens for any browser based on Qt WebKit, mobile or
> desktop. So to keep it short, we are in favor of this change and
> support spec'ing it.
> 
> Yael, do you know what issues we ran into with this change, if any?
> 
> Cheers
> Kenneth
> 
> On Mon, May 14, 2012 at 4:31 AM, James Robinson <jamesr@google.com> wrote:
>> TL;DR: position:fixed elements should establish a new stacking context.  Web
>> compat issue is minimal and a problem even if we do nothing due to "mobile"
>> browsers.
>> 
>> Consider the following
>> testcase: http://webstuff.nfshost.com/tests/fixpos.html.  On this page there
>> are two copies of a very similar DOM structure that is something like this:
>> 
>> div.container
>>  div.green
>>  div.pink
>>  div.fixed
>>   div.orange
>> 
>> with styles:
>> 
>> .container { position:absolute; }
>> .green { position:relative; z-index: 1; }
>> .pink { position:relative: z-index: 3; }
>> .fixed { position:fixed; }
>> .orange { position:relative; z-index: 2; }
>> 
>> and a second copy that is identical except for the addition of opacity:
>> 0.99; to div.fixed.
>> 
>> In the first copy, the elements green, pink, and orange are all in the
>> stacking context of container and thus the displayed order is (from back to
>> front) green, orange, pink.  In the second, the opacity property on the
>> fixed div establishes a new stacking context that displays "below" the
>> positive z-indexed children of container and so the final displayed order is
>> orange, green, pink.  Try scrolling up and down a few times on the test page
>> to get a feel for how it behaves (div.fixed is blue on the test page to make
>> it easier to see).  This behavior is spec'd reasonably well
>> in http://www.w3.org/TR/CSS2/zindex.html and there is strong
>> interoperability across desktop browsers - the rendering of this simple
>> testcase is identical in my testing of Google Chrome, Safari, Firefox,
>> Opera, and IE9.  However, the situation on mobile is not so consistent.
>> 
>> On touch-based devices, responsiveness to touch events and in particular
>> scrolling is essential to providing a good user experience.  Users really
>> notice if the page is "behind" their finger.  As a result, browsers go to
>> great lengths to provide a good scrolling experience.  A big part of this
>> is decomposing a web page into portions that move when the page scrolls and
>> portions that do not, then moving these portions relative to each other on a
>> dedicated thread.  Stacking contexts render atomically so a page can always
>> be divided into the stuff "behind" the stacking context, the stacking
>> context's content, and the stuff "above" the stacking context (with the
>> minor wrinkle that the background of an element appears "below" its negative
>> z-index children).  Elements that are position:fixed but do not form a
>> stacking context are difficult - the browser would like to separate out the
>> parts that do not scroll with the page, but that may include elements that
>> participate in z-index lists of stacking contexts outside the position:fixed
>> subtree.  It would be at least in theory possible to detangle this
>> situation, but the complexity is daunting and as far as I know nobody has
>> attempted this yet.
>> 
>> As a result, in MobileSafari on iOS 5+ and the most recent Android browser
>> position:fixed elements establish a new stacking context.  As a result, the
>> two test cases in http://webstuff.nfshost.com/tests/fixpos.html render
>> identically to each other.  Firefox on Android appears to render the same
>> way as desktop Firefox, and scrolling is quite janky.  Chrome on Android
>> Beta does something more complicated on this page that results in a
>> desktop-like rendering, but I consider that a bug (hey, it's Beta) and
>> intend to bring its behavior in line with MobileSafari.  I do not have
>> access to any Windows Phone devices, but I'm curious what its browser does.
>> 
>> This was an incompatible change in rendering for the browsers that have
>> adopted the non-desktop behavior.  Our experience in the Google-produced
>> browsers on Android is that there were a very small number of compatibility
>> issues noticed (less than 5, including some unreleased Google properties not
>> yet part of the public web).  Anecdotally I understand that Apple ran in to
>> exactly one broken website when they made this change for the iOS 5 browser.
>>  There are some other situations that render differently besides the test
>> case I've constructed, but they all fall in to the bucket of things that I
>> consider "weird" no matter how they are rendered.  We've also received a few
>> bug reports on the desktop Chrome browser where authors believed that
>> position:fixed elements were supposed to form a stacking context and were
>> surprised that adding a transform changed the z-ordering of the page.
>> 
>> This is a fairly niche area, but I think the current situation is untenable.
>>  The same implementation concerns that apply to the current set of mobile
>> browsers apply to the next generation of "desktop" browsers - consider
>> things like Win8 devices with touchscreens, larger tablets with external
>> keyboards, etc.  New content that is developed for and tested on browsers
>> like MobileSafari may render differently on desktop browsers.  I think this
>> divergence in behavior is bad for the web platform - even within the "same"
>> browser there are different behaviors on different devices, and as an
>> implementor I'll have to pick somewhat arbitrarily what a given webpage
>> gets.
>> 
>> I think the best option is to specify that position:fixed elements always
>> establish a new stacking context and have all browsers change to this
>> behavior as quickly as possible.  Based on Apple's and our experiences on
>> mobile browsers, the web compatibility impact of this change should be quite
>> minimal.  In fact, I expect that this change in behavior will be considered
>> a bug fix by at least some authors as the currently-specified behavior is
>> quite strange in most cases.
>> 
>> The next best option, and one I consider fairly difficult, would be to say
>> that we really do want the currently-specified behavior everywhere and
>> modify the current round of mobile browsers to do this.  This would be quite
>> difficult (I'm not sure if it's possible) and given the adoption of the
>> browsers with the currently divergent behavior won't really help all that
>> much with the web compatibility issue.
>> 
>> The absolute worst option would be to do nothing or to put this proposal in
>> some procedural limbo.  Mobile browsers and pages designed for mobile
>> browsers are only going to grow in popularity so the divergence in behavior
>> is going to grow more prevalent over time.
>> 
>> I am particularly interested in what non-WebKit browser vendors feel about
>> this issue.
>> 
>> - James
> 
> 
> 
> -- 
> Kenneth Rohde Christiansen
> Senior Engineer
> Nokia Mobile Phones, Browser / WebKit team
> Phone  +45 4093 0598 / E-mail kenneth at webkit.org
> 
> http://codeposts.blogspot.com ﹆﹆﹆
>

Received on Wednesday, 16 May 2012 15:58:00 UTC