Bug 185342 – Request for interop of vh unit on (and within) fixed position scheme

• Status: RESOLVED
• Resolution: FIXED
• Component: CSS

[jonjohnjohnson]

Not here to rehash the age old debate of how to fix developers issues with vh/vw regarding ICB/resize/scrollbars/keyboards (http://nicolas-hoizey.com/2015/02/viewport-height-is-taller-than-the-visible-part-of-the-document-in-some-mobile-browsers.html)(https://medium.com/samsung-internet-dev/toolbars-keyboards-and-the-viewports-10abcc6c3769)(https://adactio.com/journal/11690)...

But if we cannot get a vh unit that describes the height of a window/document that lacks scrollable overflow (which I understand the issues of breaking current sites and changing value if/when overflow happens), could we at least get interoperability with chrome when it comes to the vh unit on/within an element that is fixed positioned?

Though there may be some current websites that would have *slight differences here, when sizing fixed elements with vh units, I'm guessing anytime this happens the author desired the vh be how chrome implements it. And I understand that though it's still not ideal to have vh units resolve differently based upon position scheme, I'm guessing it's the desired behavior by most/all developers.

Also, I request "on/within", because ideally vh on any element within a fixed positioned element would match the vh on that ancestor which fixes to the viewport.

Chrome's article on moving towards interop with Safari - https://developers.google.com/web/updates/2016/12/url-bar-resizing

"There is one exception to the above changes and that is for elements that are position: fixed. Their behavior remains unchanged. That is, a position: fixed element whose containing block is the ICB will resize in response to the URL bar showing or hiding. For example, if its height is 100% it will always fill exactly the visible height, whether or not the URL bar is shown. Similarly for vh lengths, they will also resize to match the visible height taking the URL bar position into account."


David Bokan's interop explainer - http://github.com/bokand/URLBarSizing
David Bokan's demo - http://bokand.github.io/demo/urlbarsize.html
Encompasses this bug, but not suggesting same solution - https://bugs.webkit.org/show_bug.cgi?id=143305

[jonjohnjohnson]

- http://nicolas-hoizey.com/2015/02/viewport-height-is-taller-than-the-visible-part-of-the-document-in-some-mobile-browsers.html
- https://medium.com/samsung-internet-dev/toolbars-keyboards-and-the-viewports-10abcc6c3769
- https://adactio.com/journal/11690

[Simon Fraser (smfr)]

Wouldn't it be confusing if a 100vh position:fixed element didn't have a height of innerHeight?

[jonjohnjohnson]

[e-mail] Maybe, but if it's what blink has resorted to in this already murky space, I'm just asking for real interop. Especially if it makes vh units more usable than they currently.

[Brent Fulgham]

@Sam: Is there action we should take here?

[Sam Sneddon [:gsnedders]]

I think dvh does everything wanted here?

[Jen Simmons]

Yes. The solution to the quandary about what to do with VH is to define and implement SVH, LVH and DVH. That way web developers have whichever you want for the usecase at hand.