Summary: | Request for interop of vh unit on (and within) fixed position scheme | ||
---|---|---|---|
Product: | WebKit | Reporter: | jonjohnjohnson <hi> |
Component: | CSS | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED FIXED | ||
Severity: | Normal | CC: | bfulgham, gsnedders, jensimmons, nicolas, simon.fraser, zalan |
Priority: | P2 | ||
Version: | Safari 11 | ||
Hardware: | iPhone / iPad | ||
OS: | Unspecified |
Description
jonjohnjohnson
2018-05-04 20:57:19 PDT
- 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 Wouldn't it be confusing if a 100vh position:fixed element didn't have a height of innerHeight? simon.fraser@apple.com 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. @Sam: Is there action we should take here? I think dvh does everything wanted here? 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. |