Intent to Ship: Top Controls don't resize initial containing block and vh units

[David Bokan]

Contact emails

bo...@chromium.org

Spec

https://github.com/bokand/URLBarSizing

Summary

This isn't really a new feature, it's more of a change to improve interop with Safari and improve user experience. I was debating sending a PSA but decided to send out an intent as the compat impact is non-trivial.

The details are in an explainer at the "Spec" link above but in summary:

1) Today, the initial containing block is resized each time the top controls (aka URL bar) are shown/hidden. This means an element with a percentage based height will change size whenever the user changes scroll direction (causing relayout, potentially losing their place). Chrome is the only mobile browser that does this. This intent proposes that we fix the ICB to the "smallest possible" viewport (like Safari) so that height:100% will fill the viewport when the top controls are showing. Hiding the top controls will not resize the ICB (elements that are position: fixed, however, will be resized - their ICB remains the dynamically sized viewport).

2) Similarly, vh units are also dynamic today w.r.t. the top controls. This makes them virtually unusable since things like fonts will change size as the user scrolls around the page. The proposal here makes vh units relative to the "largest possible" viewport (to match Safari) so that 100vh will fill the viewport when the top controls are hidden. Likewise, hiding/showing the top controls will not change the size of a vh-sized elements.

Link to “Intent to Implement” blink-dev discussion

Not really an official intent-to-implement but some initial discussion on input-dev:

Initial discussion

Posted explainer and followup discussion

Original design/proposal doc

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

This intent affects only Android since it's the only platform with movable top controls.

Demo link

I've put up an APK demonstrating the change on the linked github. To see the difference, I've put together a demo page.

Interoperability and Compatibility Risk

Top Controls behavior is something that's completely unspec'd and, until now, browsers have all behaved differently, making developer's lives painful. This change aligns us more closely with Safari so I expect interop to improve here. Ideally, we'd eventually collaborate with other vendors to write some kind of document (if not a spec) on how top controls affect pages.

That said, this is a fairly visible change and could affect existing pages. I've tried this out on many popular pages (Facebook, G+, Twitter, etc.) and haven't seen anything break (most pages don't rely on the viewport size vertically). The failure mode shouldn't be critical either since the page will simply remain as it looked at load; the most convincing argument is that Safari's been doing this for years without user/developer complaint, UA sniffing aside. My plan here is to closely monitor any breakages in beta and revert if the pain is non-trivial.

In terms of functionality, developers can still easily revert to the old mode with a little bit of javascript: add a resize handler that sizes the document element explicitly to the window.innerHeight.

Signals from other vendors:

Apple - None but we're essentially moving to their model

Firefox - Mildly positive signal in input-dev discussion

Edge/IE - N/A; Non resizing top controls

WebDevs - The original motivation for this was bug 428132 - 51 stars. Positive support from G+/AMP team.

OWP launch tracking bug

N/A

Entry on the feature dashboard

None - This isn't really a new feature. It's a change in how our browser UX interacts with the page.

[Chris Harrelson]

LGTM1.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Chris Harrelson]

..make that LGTM1 to ship in M50. Let's provide maximum time to developers to adjust. I assume we'll do some blog posting and outreach to bring the good news?

[PhistucK]

So 100% will be the minimal viewport height and 100vh will be the maximal viewport height? :|

This sounds so backwards. :(

☆PhistucK

[David Bokan]

On Tuesday, January 19, 2016 at 11:39:19 AM UTC-5, PhistucK wrote:

So 100% will be the minimal viewport height and 100vh will be the maximal viewport height? :|

This sounds so backwards. :(

I agree this sounds odd, and originally I wanted to make them the same (I tried reaching out to Safari engineers to see if we could convince them of this but I got the silent treatment). In the end, I think the benefit of being compatible with Safari outweighs the minor inconsistency in mental model.

[PhistucK]

Well, I guess you can try that.

Hopefully (or not?), it will not end up like one of the touch trials that ended up being changed multiple times...

☆PhistucK

--

[Rick Byers]

I agree that consistency with Safari outweighs minor differences in details like this.  If we had strong signals from developers that a different model was better, that could be justification to do something different and try to convince Safari to change.  But absent that, let's just match Safari.

LGTM2 to ship

[Philip Jägenstedt]

LGTM3

I also agree that the model seems a bit inconsistent, but if it's a problem we should probably look at new APIs to control it rather than changing the defaults.

[nic...@hoizey.com]

Hi there,

I’m not at all involved in browsers development, I’m more in the users and web developers sides.

You tell us that “Safari’s been doing this for years without user/developer complaint”… Well, how do you know nobody complained?

I, for example, complained in a post on my blog almost a year ago: http://nicolas-hoizey.com/2015/02/viewport-height-is-taller-than-the-visible-part-of-the-document-in-some-mobile-browsers.html

And I didn’t only complain, as suggested by Yoav Weiss, I opened a few bugs/issues on Apple Bug Reporter and Webkit Bugzilla, and even talked (on Twitter) with the W3C CSS Working Group.

And I’m not the only one complaining at all.

There is a “buggyfill” library that initialy aimed to solve iOS < 8 issues with viewport units, but people still believe the way iOS Safari deals with vh nowadays is still a bug

It’s really a pain to develop full-viewport (not really full-screen) interfaces, like I am with my game esviji with such a behavior of the vh unit. You never know if you really use the full visible height, or less, or more…

I do understand, through, that other components in the page, if not using 100vh can behave strangely for users in current Chrome for Android implementation. A friend told me so a few month ago, because some elements in my blog design use the vw and vh units for fluid responsiveness (instead of step by step responsiveness with Media Queries).

So I know it’s not an easy decision, and I know that “improve interop with Safari” is a big motivation when even Mozilla makes Firefox compatible with -webkit- prefixes.

But I know you can’t say “Safari’s been doing this for years without user/developer complaint” without me banging my head against the wall…

I’m not sure I will make you change anything in the process, but at least I gave you my different point of view.

-Nicolas

[David Bokan]

Sorry, I clearly hit a nerve. My quote was in the context of compatibility; a page that "breaks" as a result of this change will look like it does in Safari, which developers have either worked with or worked around. I didn't mean to say it was easy or pleasant.

I actually replied on the bug you filed with WebKit but got no reply. Given that Safari intentionally chose the "larger viewport" they're unlikely to change now. I think there's use cases for both arguments (smaller and larger viewport) but at the end of the day, even if we have "the same 'bug' everywhere", I think it's preferable that we have interoperable implementations. At least you can work around one set of bugs :).

[Nicolas Hoizey]

Hi David,

2016-01-20 16:01 GMT+01:00 David Bokan <bo...@chromium.org>:

Sorry, I clearly hit a nerve.

Indeed… ;-)

 

My quote was in the context of compatibility; a page that "breaks" as a result of this change will look like it does in Safari, which developers have either worked with or worked around. I didn't mean to say it was easy or pleasant.

Ok.

 

I actually replied on the bug you filed with WebKit but got no reply. Given that Safari intentionally chose the "larger viewport" they're unlikely to change now.

I agree, unfortunately.

 

I think there's use cases for both arguments (smaller and larger viewport) but at the end of the day, even if we have "the same 'bug' everywhere", I think it's preferable that we have interoperable implementations. At least you can work around one set of bugs :).

I do agree to that interoperability is the best thing to aim for, always, even if it sometimes means Mozilla will start supporting webkit prefixes.

I'm just sad you change your perfect (IMHO) implementation, instead of them… ;-)

The best thing would have to be interoperability of default behavior, and a standard way to change the behavior, like with box-sizing for example.

-Nicolas

--

Nicolas Hoizey

Visitez 📷 mes photos, 📝 mon blog et 🎮 mon jeu !

[Philip Jägenstedt]

On Wed, Jan 20, 2016 at 11:02 PM, Nicolas Hoizey <nic...@hoizey.com> wrote:

The best thing would have to be interoperability of default behavior, and a standard way to change the behavior, like with box-sizing for example.

This I agree with. David, have you talked about any APIs for influencing these behaviors?

Philip

[David Bokan]

Not yet, but I agree that's an promising direction to look at. I've replied in more detail on the input-dev thread: https://groups.google.com/a/chromium.org/forum/#!topic/input-dev/EBNboiECIAQ

[John Mellor]

Sorry to throw spokes in the wheels, but I'm really worried about this change. You're proposing the following behaviors (changes in bold):

Property                       |  mobile url bar   | desktop scrollbars |

-------------------------------+-------------------+--------------------+

CSS html { height:100%; }      |     excluded      |      excluded      |

CSS position:fixed;height:100% | depends on scroll |      excluded      |

CSS html { height:100vh; }     |     included      |      included      |

CSS position:fixed;height:100vh|     included      |      included      |

CSS @media height              |     excluded      |      included      |

JS doc.docElement.clientHeight |     excluded      |      excluded      |

JS window.innerHeight          | depends on scroll |      included      |

That's 5 different combinations of behaviors, for properties that are all expected to evaluate to "viewport height". Most web developers will initially expect these all to be the same, and over time having been bitten might be aware of 2 or 3 of them, but this is super gnarly.

To take a concrete example, after this change, how would you implement a basic layout template:

SIDENAV | CONTENT

where if the content is short, the sidenav should still extend all the way to the bottom of the window?

If you set min-height:100% on the sidenav, it'll be too short when the top controls are hidden. If you set min-height:100vh on the sidenav, it'll be too long when the top controls are showing (i.e. it'll force the page to be scrollable when it wouldn't have been necessary). If you size the page using position:fixed, then the sidenav will be the right height, but this prevents the page from being scrolled; you could hackily add overflow:scroll, but then scrolling will behave weirdly, e.g. it won't cause the top controls to hide. There seems to no longer be any way to implement such a trivial design using pure CSS, even in a single browser.

From an ease of development point of view, Chrome's existing behavior seemed a lot better: the page would resize from time to time, which websites have to handle anyway, but otherwise all these heights returned the same values.

Or if we consider the performance benefits of fixed-height ICBs to be overwhelming (even though we still have to relayout position:fixed elements), then it seems that Firefox's approach might have made more sense, i.e. always include the top controls (use the largest viewport), unless the page is too short to require scrolling, in all of the CSS and JS properties (except perhaps the position:fixed ones, though that's a bit messy), so that at least these values are all consistent.

As to Safari-compatibility, It's not clear from webkit.org/b/141832 that Safari has considered the web developer inconsistency cost of their approach, so it seems worth discussing this further with them.

[Elliott Sprehn]

On Jan 21, 2016 10:36 AM, "John Mellor" <joh...@chromium.org> wrote:
>
> Sorry to throw spokes in the wheels, but I'm really worried about this change. You're proposing the following behaviors (changes in bold):
>
> Property                       |  mobile url bar   | desktop scrollbars |
> -------------------------------+-------------------+--------------------+
> CSS html { height:100%; }      |     excluded      |      excluded      |
> CSS position:fixed;height:100% | depends on scroll |      excluded      |
> CSS html { height:100vh; }     |     included      |      included      |
> CSS position:fixed;height:100vh|     included      |      included      |
> CSS @media height              |     excluded      |      included      |
> JS doc.docElement.clientHeight |     excluded      |      excluded      |
> JS window.innerHeight          | depends on scroll |      included      |
>
> That's 5 different combinations of behaviors, for properties that are all expected to evaluate to "viewport height". Most web developers will initially expect these all to be the same, and over time having been bitten might be aware of 2 or 3 of them, but this is super gnarly.
>
> To take a concrete example, after this change, how would you implement a basic layout template:
> SIDENAV | CONTENT
> where if the content is short, the sidenav should still extend all the way to the bottom of the window?
>

Use flexbox, vh units are not the solution to this.

> ...

>
> As to Safari-compatibility, It's not clear from webkit.org/b/141832 that Safari has considered the web developer inconsistency cost of their approach, so it seems worth discussing this further with them.

Seems worth a shot, but given how much content targets iOS I think developers are already dealing with this okay.

- E

[David Bokan]

On Thursday, January 21, 2016 at 1:36:05 PM UTC-5, John Mellor wrote:

Sorry to throw spokes in the wheels, but I'm really worried about this change. You're proposing the following behaviors (changes in bold):

Property                       |  mobile url bar   | desktop scrollbars |

-------------------------------+-------------------+--------------------+

CSS html { height:100%; }      |     excluded      |      excluded      |

CSS position:fixed;height:100% | depends on scroll |      excluded      |

CSS html { height:100vh; }     |     included      |      included      |

CSS position:fixed;height:100vh|     included      |      included      |

CSS @media height              |     excluded      |      included      |

JS doc.docElement.clientHeight |     excluded      |      excluded      |

JS window.innerHeight          | depends on scroll |      included      |

That's 5 different combinations of behaviors, for properties that are all expected to evaluate to "viewport height". Most web developers will initially expect these all to be the same, and over time having been bitten might be aware of 2 or 3 of them, but this is super gnarly.

To take a concrete example, after this change, how would you implement a basic layout template:

SIDENAV | CONTENT

where if the content is short, the sidenav should still extend all the way to the bottom of the window?

If you set min-height:100% on the sidenav, it'll be too short when the top controls are hidden. If you set min-height:100vh on the sidenav, it'll be too long when the top controls are showing (i.e. it'll force the page to be scrollable when it wouldn't have been necessary). If you size the page using position:fixed, then the sidenav will be the right height, but this prevents the page from being scrolled; you could hackily add overflow:scroll, but then scrolling will behave weirdly, e.g. it won't cause the top controls to hide. There seems to no longer be any way to implement such a trivial design using pure CSS, even in a single browser.

 

If you can scroll the page, and the sidenav is non-fixed, I don't think it matters that it's too short when the top controls are hidden since it looks right on load and you'll be scrolling the sidenav away anyway - it doesn't stay in the viewport. Ditto for 100vh and sidenav being too long (it's cut off on load which is a problem, but in that case use height:100%). I think the major use case for resizing elements to the viewport is position: fixed, when you have an element you want to keep in the viewport persistently. 

From an ease of development point of view, Chrome's existing behavior seemed a lot better: the page would resize from time to time, which websites have to handle anyway, but otherwise all these heights returned the same values.

I agree it was a lot less messy, but it's not without its problems. Consider bug 428132 and how many people were surprised that their fonts (sized by vh) are changing size as the user scrolls. In general, I think the URL bar is a  transient piece of UI that comes in and out, I don't think we should be trying to respond and relayout each time. This has both performance implications and user experience. I've seem several sites that have images or elements with a percentage or vh height set. When the user flings down on one of these pages, as soon as the fling ends they lose their place as the page does a layout. I think the intuition is that UI, like top controls and on screen keyboard, are an overlay on the page. IMO, we shouldn't be affecting the content in response to these. I think it can be surprising to developers and a poor experience for users.

 

Or if we consider the performance benefits of fixed-height ICBs to be overwhelming (even though we still have to relayout position:fixed elements), then it seems that Firefox's approach might have made more sense, i.e. always include the top controls (use the largest viewport), unless the page is too short to require scrolling, in all of the CSS and JS properties (except perhaps the position:fixed ones, though that's a bit messy), so that at least these values are all consistent.

I would actually argue for the opposite and exclude the top controls on all the properties. The argument being that the page should look correct on first load when the top controls are showing. Once you start scrolling and the top controls start to move out of the way, I think the expectation of filling the viewport is removed. I do agree that having the properties be all "smallest viewport" or all "largest viewport" is preferable, in either case, though I would argue compatibility outweighs consistency in this case.

As to Safari-compatibility, It's not clear from webkit.org/b/141832 that Safari has considered the web developer inconsistency cost of their approach, so it seems worth discussing this further with them.

I've tried contacting Apple folks both through email and their bug tracker but got no where so I'm not terribly hopeful. +rbyers@ who may have some face-to-face time soon with Safari engineers and can perhaps bring this on their radar. I would love if they switched vh to be "smallest viewport" and we could have a simpler story. I don't actually see the use case for "larger viewport" since the user has to hide the top controls manually to see the effect.

Thanks,

David

[gareth....@guardian.co.uk]

Good Morning,

Just wondering whether there has been any progress on this since January? We use 100vh various places on the Guardian now and we have to do a hacky JS height fix to work around the issue but I know it is preventing us using vh units more widely.

An update or pointers would be great!

Cheers,

Gareth

[David Bokan]

Hi Gareth,

There have turned out to be some subtleties I need to look into before shipping this change and it's slipped off my plate in the last little while but it is still on my radar and I'm looking to dedicate most of my time to this in the coming weeks. I'll post updates to bug 428132 so feel free to star it to get updates.

Thanks,

David

---

This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way.  Guardian News & Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software.

 

Guardian News & Media Limited is a member of Guardian Media Group plc. Registered Office: PO Box 68164, Kings Place, 90 York Way, London, N1P 2AP.  Registered in England Number 908396

[Gareth Trufitt]

Great, thanks for the update David - appreciate that. If we can do anything to help test or input into this, let me know. I've starred the bug.

Cheers,

Gareth

[bo...@google.com]

tl;dr: I'm going to ship this change in M56.

I've finally had time to take a look at this again. The problems I saw earlier were all related to background-attachment: fixed not resizing. I have a fix for that in review at crrev.com/2461463004, after which I'm going to ship this flag in M56. Given that this already got the necessary LGTMs when originally proposed, I'll move forward unless anyone objects.

One change worth noting: unfortunately, Firefox mobile has actually moved to our current model in the mean time. I still think we should ship. Interop with Safari will be good for the web. It's still possible for authors to resize layout in response to top controls if they really want that with a bit of javascript and the default should err to improved performance. vh units are a bit more tricky but I think we should introduce an API for controlling what they mean.

An additional data point is that I've run wangxianzhu@'s paint invalidation metric on the telemetry cluster (crbug.com/289097) to measure the effect of this change on paint invalidation on the top 10K. The results show we cut our invalidations when hiding top controls in half with this change:

Total Pages: 8338
Pages without any paint invalidation: 5623.500
Pages with full invalidation: 0
Pages with partial invalidation: 2714.5

vs. without change:

total pages tested: 7951

pages without any paint invalidation: 2212

pages with full paint invalidation: 1

pages invalidated paint because of style and/or layout change: 5738.

So in addition to improving authors lives, this should be a performance/battery benefit to users as well.

[Boris Zbarsky]

On 11/2/16 10:02 AM, bokan via blink-dev wrote:
> One change worth noting: unfortunately, Firefox mobile has actually
> moved to our current model in the mean time. I still think we should
> ship.

I haven't really been following this thread, but I would appreciate it
if you would file a bug explaining what the change here is on Firefox.
Please cc me on that bug.

-Boris

[David Bokan]

Hi Boris,

The change was intentional and is tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1180295. FWIW, we've discussed this change with kats a while back in this input-dev thread and the changes necessary for Firefox to match us and Safari here aren't very big.

[Boris Zbarsky]

On 11/2/16 10:54 AM, David Bokan wrote:
> The change was intentional and is tracked
> in https://bugzilla.mozilla.org/show_bug.cgi?id=1180295. FWIW, we've
> discussed this change with kats a while back in this input-dev thread

> <https://groups.google.com/a/chromium.org/forum/#!searchin/input-dev/Explainer$20URL$20Bar/input-dev/lBZvTtolw-A/fx2grCmKCAAJ> and

> the changes necessary for Firefox to match us and Safari here aren't
> very big.

Right, I'd just like there to be a record of the changes needed in
Firefox to align with Safari and your new behavior somewhere, so we can
make them and everyone can agree.

-Boris

[David Bokan]

Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1314686

[Boris Zbarsky]

On 11/2/16 1:52 PM, David Bokan wrote:
> Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1314686

Perfect, thank you very much!

-Boris

[Rick Byers]

I think Developers might notice this change and want to understand the difference.  Can you please create a chromestatus entry with a link to your repo to ensure this gets mentioned in the blog post and increase the chance that developers can find the details?

Thanks,

   Rick

[bo...@google.com]

Done, I'll paste the link once it shows up.

I'll reach out to dev-rel once I'm certain it'll stick, this is something people might want to know about.

[David Bokan]

Chromestatus entry: https://www.chromestatus.com/features/6241601772847104