Top Control Resizes

25 views
Skip to first unread message

bo...@chromium.org

unread,
Oct 8, 2015, 3:56:47 PM10/8/15
to input-dev
Hello input-dev,

Top controls are an ill-specified part of the platform and cause headaches for developers and users alike. I think Chrome in particular is bad here. I've summarized the issues, various browser differences, and potential changes in a design doc: https://docs.google.com/document/d/1kyOHTOJ_qcapdaxChds_hSBG3nSpawllEQoHvtMEcvA/edit?usp=sharing

Let me know what you think

Alexandre Elias

unread,
Oct 9, 2015, 7:32:28 PM10/9/15
to David Bokan, input-dev
I was a bit skeptical at first that it might complexify the platform, but I'm on board now with the main idea here (that "vh" units and percentage-based heights for non-fixed-pos elements should be against a fixed height).  The two most convincing points for me are that:
1) In the status quo, "vh" units are basically an awful misfeature that should almost never be used.  But popularity of it is increasing and it's seen as a great feature for responsive design.  This justifies corrective action even if it makes the platform viewporting story a bit more complex.
2) iOS Safari has already adopted this behavior and the comments on https://bugs.webkit.org/show_bug.cgi?id=141832 indicate they feel strongly about it and are unlikely to change, so this will improve compatibility.

PhistucK

unread,
Oct 21, 2015, 8:52:27 AM10/21/15
to Alexandre Elias, David Bokan, input-dev
As a web developer, following Safari will be a real downgrade. This simply encourages developers to use JavaScript instead of CSS and that is never what you want.
Also as a web developer, the top-controls-disappear-while-scrolling feature is also a pretty awful feature. For some reason, almost every browser adopted it (I understand the purpose, which is fair - more real estate on mobile), even though it is simply developer (and sometimes user) hostile.
Hiding the top controls creates some sort of a full screen situation which can be deceiving for the user, if it is used in the wrong manner.


PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to input-dev+...@chromium.org.

David Bokan

unread,
Oct 21, 2015, 10:42:31 AM10/21/15
to PhistucK, Alexandre Elias, input-dev
On Wed, Oct 21, 2015 at 8:51 AM, PhistucK <phis...@gmail.com> wrote:
As a web developer, following Safari will be a real downgrade. This simply encourages developers to use JavaScript instead of CSS and that is never what you want.

What about the proposal do you see as a problem? The basic premise is that we wont be resizing the initial containing block every time the top controls show/hide. This allows developers to use more CSS, not less (vh units become practical, for instance). 

Also as a web developer, the top-controls-disappear-while-scrolling feature is also a pretty awful feature. For some reason, almost every browser adopted it (I understand the purpose, which is fair - more real estate on mobile), even though it is simply developer (and sometimes user) hostile.
Hiding the top controls creates some sort of a full screen situation which can be deceiving for the user, if it is used in the wrong manner.

I agree that top control hiding makes life more difficult for developers but I think this proposal alleviates some of that pain. This is an area where we (rightly, IMO) lean towards satisfying users rather than developers. That said, I'd like to move in a direction where a simple, naively written app interacts well with top controls (that's not the case today) but expose enough information and hooks so that sophisticated developers can work around them. Having compatible implementations will go a long way to making this easier on webdevs.

PhistucK

unread,
Oct 21, 2015, 11:42:34 AM10/21/15
to David Bokan, Alexandre Elias, input-dev

On Wed, Oct 21, 2015 at 5:42 PM, David Bokan <bo...@google.com> wrote:
What about the proposal do you see as a problem? The basic premise is that we wont be resizing the initial containing block every time the top controls show/hide. This allows developers to use more CSS, not less (vh units become practical, for instance). 

​The fact that stuff will be hidden from the viewport if you use 100vh and depend on that height for placements. Like in Safari​, where the bottom bar hides page content.



PhistucK

David Bokan

unread,
Oct 21, 2015, 11:45:20 AM10/21/15
to PhistucK, Alexandre Elias, input-dev
That's the one place we're diverging from Safari, 100vh will not include the top controls. The flip side is that 100vh will not be the full viewport height when the top controls are hidden - but if you want something to fill the viewport through a scroll you can use position: fixed; height: 100% which will still behave as today (they'll be resized to fill exactly the visual viewport).

PhistucK

unread,
Oct 21, 2015, 11:56:41 AM10/21/15
to David Bokan, Alexandre Elias, input-dev
This sucks as well, there will be a gap at the bottom. You are trying to fit two shapes into one, this does not make sense. I understand it is hard and not performant, but that is hardly a good reason to create such an ilogical behavior.


PhistucK

David Bokan

unread,
Oct 21, 2015, 12:40:24 PM10/21/15
to PhistucK, Alexandre Elias, input-dev
For "splash" pages where you want the initial view to show a 100% banner/splash of some kind, the "gap" isn't really a gap since the user can scroll the element out of the viewport an arbitrary amount; it's no different than just scrolling down some. It's not meant to always fill the viewport, just initially.

The one case I can think of where this might matter is if you want a "paginated" document, where scrolling down reveals some viewport-sized element. I think this case is rare while our current behaviour is hostile to most pages that use vh units or percentage based heights (lots). Even so, you could still fairly easily solve this either through javascript (emulating our current model), disabling top controls by using a scrolling div, or making your content position: fixed.

I also disagree with the premise, performance is often a valid reason for sacrificing some conceptual purity. I think in this case, we're making the majority of content behave more rationally but there's still an escape hatch to do everything you can today.
Reply all
Reply to author
Forward
0 new messages