[Webkit-unassigned] [Bug 185342] New: Request for interop of vh unit on (and within) fixed position scheme

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=185342

            Bug ID: 185342
           Summary: Request for interop of vh unit on (and within) fixed
                    position scheme
           Product: WebKit
           Version: Safari 11
          Hardware: iPhone / iPad
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: CSS
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: hi at jonjohnjohnson.com

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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180505/5807d3ce/attachment-0001.html>