Viewport Unit Issues Was:"Intent to Ship: Top Controls don't resize initial containing block and vh units"

[David Bokan]

Hi Nicolas,

I wanted to follow up on some of the issues you mentioned to either help or get a better idea where we should invest our efforts.

What are some of the shortcomings in the "buggyfill" you mentioned? It should be able to reliably size the vh units to the "smaller viewport" using document.clientHeight. I imagine things like media queries might present a challenge. Does it just break down in edge cases or is it broken in some fundamental ways?

Additionally, why not use the fullscreen API? Or size your elements using percentage based sizes, which are relative to the "smaller viewport"?

Thanks,

David

 

On Tuesday, January 19, 2016 at 5:38:43 PM UTC-5, nic...@hoizey.com wrote:

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

[Nicolas Hoizey]

Hi David,

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

Hi Nicolas,

I wanted to follow up on some of the issues you mentioned to either help or get a better idea where we should invest our efforts.

Thanks a lot for this effort, it is much apreciated.

What are some of the shortcomings in the "buggyfill" you mentioned? It should be able to reliably size the vh units to the "smaller viewport" using document.clientHeight.

First, I’m not really happy to rely on JS code to define elements sizes and positions when CSS should be enough and more robust.

I imagine things like media queries might present a challenge. Does it just break down in edge cases or is it broken in some fundamental ways?

There are indeed issues when using Media Queries, as you can see in the discussion in this issue.

Additionally, why not use the fullscreen API?

First, it requires an action from the user, not really good UX IMHO.

And last time I checked, it wasn’t really safe trying to rely on this for every browser. I don’t see much green in caniuse for this feature.

Or size your elements using percentage based sizes, which are relative to the "smaller viewport"?

Some vertical sizes expressed in percentage are based on width of their parent instead of their height, isn’t it?

Thanks,

David

 

On Tuesday, January 19, 2016 at 5:38:43 PM UTC-5, nic...@hoizey.com wrote:

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

​

--

Nicolas Hoizey

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

[David Bokan]

What are some of the shortcomings in the "buggyfill" you mentioned? It should be able to reliably size the vh units to the "smaller viewport" using document.clientHeight.

First, I’m not really happy to rely on JS code to define elements sizes and positions when CSS should be enough and more robust.

I imagine things like media queries might present a challenge. Does it just break down in edge cases or is it broken in some fundamental ways?

There are indeed issues when using Media Queries, as you can see in the discussion in this issue.

Difficulty in polyfilling a feature is a good signal that we're missing some more fundamental APIs. CSS features in particular are tough to work around. I don't think it's impossible in this case though I imagine it's not performant and subverts the style system. I think you're right in that we may want to add a property that lets the author decide whether they want the "largest possible" or "smallest possible" viewport (and maybe even dynamic where vh's resize when top controls hide, which is our current model) when referring to vh/vw units. I'll have to ponder it over whether that's the best solution (and also how likely are other browsers to adopt it).

Additionally, why not use the fullscreen API?

First, it requires an action from the user, not really good UX IMHO.

And last time I checked, it wasn’t really safe trying to rely on this for every browser. I don’t see much green in caniuse for this feature.

Hmm, I hadn't realized iOS Safari doesn't support fullscreen at all. Sadness...

Or size your elements using percentage based sizes, which are relative to the "smaller viewport"?

Some vertical sizes expressed in percentage are based on width of their parent instead of their height, isn’t it?

 They should always be based on height, though (I think what you're saying) is it doesn't always work in cases where nested in other boxes, which is true. FWIW, if you make your elements position:fixed they'll get their size from the dynamic viewport (i.e. resize in response to top controls) but then you have to worry about positioning them manually.

[bo...@chromium.org]

On Thursday, January 21, 2016 at 11:16:46 AM UTC-5, David Bokan wrote:
> Some vertical sizes expressed in percentage are based on width of their parent instead of their height, isn’t it?
>  They should always be based on height, though (I think what you're saying) is it doesn't always work in cases where nested in other boxes, which is true. FWIW, if you make your elements position:fixed they'll get their size from the dynamic viewport (i.e. resize in response to top controls) but then you have to worry about positioning them manually.

I've just been informed that in some contexts using a % value does use width which can be surprising (padding?) but I think height: x% should always use a percentage of the containing block's height.

[Nicolas Hoizey]

2016-01-21 17:16 GMT+01:00 David Bokan <bo...@google.com>:

What are some of the shortcomings in the "buggyfill" you mentioned? It should be able to reliably size the vh units to the "smaller viewport" using document.clientHeight.

First, I’m not really happy to rely on JS code to define elements sizes and positions when CSS should be enough and more robust.

I imagine things like media queries might present a challenge. Does it just break down in edge cases or is it broken in some fundamental ways?

There are indeed issues when using Media Queries, as you can see in the discussion in this issue.

Difficulty in polyfilling a feature is a good signal that we're missing some more fundamental APIs. CSS features in particular are tough to work around. I don't think it's impossible in this case though I imagine it's not performant and subverts the style system. I think you're right in that we may want to add a property that lets the author decide whether they want the "largest possible" or "smallest possible" viewport (and maybe even dynamic where vh's resize when top controls hide, which is our current model) when referring to vh/vw units. I'll have to ponder it over whether that's the best solution (and also how likely are other browsers to adopt it).

Ok, thanks for considering it!

Additionally, why not use the fullscreen API?

First, it requires an action from the user, not really good UX IMHO.

And last time I checked, it wasn’t really safe trying to rely on this for every browser. I don’t see much green in caniuse for this feature.

Hmm, I hadn't realized iOS Safari doesn't support fullscreen at all. Sadness...

Yep…

[Nicolas Hoizey]

You’re right, it’s only for padding that we have this behavior. Which is useful for aspect ratio control, after all, but counter intuitive…

​