Viewport units still need a cross-browser fix

Ask developers what they'd fix in CSS, and a popular answer is viewport units. The problems come in two common flavors. First, when an element is set to 100vw and runs edge-to-edge, it's fine until a vertical scrollbar appears—then the unit becomes too wide, triggering a horizontal scrollbar since viewport units can't gracefully account for it. You may end up hiding overflow on the body when you wouldn't otherwise need to. There's a demo showing this.

Second, on mobile browsers, viewport units can help position a fixed footer, but when browser chrome—like navigation or a keyboard—appears, it may cover the footer because the mobile browser sees no change in viewport size. Matt Smith documents this issue and shows a working — if imperfect — approach.

On the left, the browser navigation bar (considered browser chrome) is covering up the footer making it appear that the footer is beyond 100vh when it is not. On the right, the -webkit-fill-available property is being used rather than viewport units to fix the problem.

He also provides a partial solution:

body {
  min-height: 100vh;
  min-height: -webkit-fill-available;
}
html {
  height: -webkit-fill-available;
}

That code was updated to target the html element after learning Chrome is changing its behavior to match Firefox.

Does this really work? […] I've had no problems with any of the tests I've run and I'm using this method in production right now. But I did receive a number of responses to my tweet pointing to other possible problems with using this (the effects of rotating devices, Chrome not completely ignoring the property, etc.)

A true cross-browser solution is still wanted, but this vendor-prefixed approach is a reasonable improvement for now. Using a prefixed property as progressive enhancement feels odd, but that's the state of things.