Another article that advocates for avoiding vh units completely because of this problem: https://chanind.github.io/javascript/2019/09/28/avoid-100vh-on-mobile-web.html

Agenda+ to make everyone read the article linked above. This is bad and we should do something about it; I'm less sure about what.

Is this behavior ever useful? Should it not be the case that if the size of the viewport changes, by way of scrollbars or due to browser chrome appearing, the size of the initial containing block changes. Or is there something special about this URL bar?

This is bad and we should do something about it; I'm less sure about what.

Agreed! As noted, my proposal doesn’t really solve the issue, but it does at least offer choice and perhaps a better default than how vh currently behaves.

But if someone comes up with a solution that makes the vh unit itself useful again I would be all for it!

Should it not be the case that if the size of the viewport changes, by way of scrollbars or due to browser chrome appearing, the size of the initial containing block changes.

That’s actually how vh units initially behaved! But it turns out that it’s a horrible UX because content would actually move/change size as you scrolled. So Safari (and later Chrome) both agreed that just fixing it to a single height would be the better UX - feel free to take a look at the two citations in my first paragraph.

I'm thinking that the issue is that we really need a good default for vh as it stands that doesn't cause data loss, because a lot of web developers do not test very comprehensively on mobile devices, instead they will drag their window small or use RWD browser tools that cause a small viewport. These methods won't highlight the appearing chrome problem you describe. It would be better to have the default for vh be unable to cause data loss even if that caused content to shift, and then add the thing people can opt into that does the other behavior. As the people opting in then presumably know what they are doing. However maybe that ship has sailed.

I'm thinking that the issue is that we really need a good default for vh

Agreed; I would love for vh to be useful again.

However maybe that ship has sailed.

Yeah, I think it has unfortunately. There have been issues opened for both browsers for years and all have been closed saying the current behavior is intentional.

vh doesn't pay attention to scrollbars, so that it can be a computed-value time unit and not depend on layout.

But nothing stops vh from responding to UA chrome hiding/showing. That's not a content-based decision, it just happens as a result of user interaction. It means we have to invalidate as the chrome disappears, but otherwise is not problematic. I think we can just clarify that the viewport units should do so.

Further question: should it respond to on-screen-keyboard showing/hiding? I suspect the answer is no, but I'm not sure what answer is most consistent.

should it respond to on-screen-keyboard showing/hiding?

I would say that yes, any feature for adjusting to URL bar show/hide behavior should also include the keyboard and any other pop-up/pop-over browser widgets that cover part of the layout viewport. Example use case: if the UI consists mostly of a large text box, it's nice to make that fill most of the window. It's less nice if the box gets covered up by the keyboard you're using to type in it, and you end up with a scrolling text box inside a scrolling window.

An alternative to adding new units would be to expose environment variables for the size of the obscured region on each side of the screen. Or maybe, include this type of obscuring in the "safe inset area" variables that are already defined.

I think we can just clarify that the viewport units should do so.

sorry, can you clarify what you mean by this? Are you proposed that vh units go back to the original behavior of changing the value of 1vh based on UA chrome?

If so, I don't think that is a better solution than the current situation -- that's how it behaved originally and it was a worse experience than what we have now. :)

(If not, sorry, can you explain what you mean? I apologize)

An alternative to adding new units would be to expose environment variables for the size of the obscured region on each side of the screen. Or maybe, include this type of obscuring in the "safe inset area" variables that are already defined.

I think that would put us back at the original behavior of vh units, which means that content actually changes size (and thus can shift underneath the user) when you scroll, right? Or am I misunderstanding your proposal?

If so, I don't think that is a better solution than the current situation -- that's how it behaved originally and it was a worse experience than what we have now. :)

Hm, I'm confused then. In what situations would it be worse? Naively, I'd think that it's the best of both worlds, neither under- nor over-flowing regardless of how the chrome is displayed.

I think that would put us back at the original behavior of vh units, which means that content actually changes size (and thus can shift underneath the user) when you scroll, right? Or am I misunderstanding your proposal?

Ah, hm, is this the issue? It's really better to have something over or underflowing than have things possibly shift when the user scrolls?

Ah, hm, is this the issue? It's really better to have something over or underflowing than have things possibly shift when the user scrolls?

Correct! At least, that's what Safari and Chrome teams agreed as well. Here's a brief history of vh units:

1. vh units are added to browsers. 1vh changes values depending on UA chrome sizes. This is a bad UX because content is constantly shifting as a user scrolls up and down the page.
2. Safari changes the value of 1vh to be whatever the height when UA chome is minimal. Here's a quote on their reasoning, around 2015:

This is completely intentional. It took quite a bit of work on our part to achieve this effect. :)

The base problem is this: the visible area changes dynamically as you scroll. If we update the CSS viewport height accordingly, we need to update the layout during the scroll. Not only that looks like shit, but doing that at 60 FPS is practically impossible in most pages (60 FPS is the baseline framerate on iOS).

It is hard to show you the "looks like shit" part, but imagine as you scroll, the contents moves and what you want on screen is continuously shifting.

Dynamically updating the height was not working, we had a few choices: drop viewport units on iOS, match the document size like before iOS 8, use the small view size, use the large view size.

From the data we had, using the larger view size was the best compromise. Most website using viewport units were looking great most of the time.

3. Chrome follows suit about a year later

So, that's how we got here -- vh units used to change dynamically, then it was determined that was horrible (and honestly it was), but now we're left with a vh value that only reflects the larger view size but not the small view size, which makes full screen designs difficult to work with.

Ah, I hadn't realized you wanted vhc to always represent the minimum viewport height (minus the pop-up chrome), even when that chrome isn't current visible.

So there are three distinct use cases:

• A stable layout that exactly fits the full viewport with minimized chrome.
• A stable layout that exactly fits the viewport when pop-up browser chrome is displayed.
• A dynamic layout that always exactly fits the current viewport, regardless of how many browser widgets are surrounding it.

Ah, I hadn't realized you wanted vhc to always represent the minimum viewport height (minus the pop-up chrome), even when that chrome isn't current visible.

So there are three distinct use cases:

• A stable layout that exactly fits the full viewport with minimized chrome.
• A stable layout that exactly fits the viewport when pop-up browser chrome is displayed.
• A dynamic layout that always exactly fits the current viewport, regardless of how many browser widgets are surrounding it.

Seems like a great summary, yes! Thank you.

I think everyone hoped that one css unit (vh) could work for all those cases (and honestly it would be awesome if it did), but I'm not entirely sure what that would look like or how it would work.

So I proposed an additional unit instead :D

* A stable layout that exactly fits the viewport when pop-up browser chrome is displayed.

If the vhc means this, it would be confusing. vhc sounds the height includes the browser chrome's height.

Also, I guess the units people really wants is the visual viewport size instead of the layout viewport.
CCing @bokand

I initially argued that vh should reflect the minimum possible size but didn't get a response from WebKiters so decided that the larger size and compat with Safari was preferable to a saner default but incompatibility with Safari.

Also, I guess the units people really wants is the visual viewport size instead of the layout viewport.
CCing @bokand

I don't think so. The visual viewport is conceptually detached from layout. i.e. if the user zooms in, the visual viewport shrinks. So we don't ever want layout to depend on visual viewport properties.

I think having a new unit for the minimum possible size sounds fine, or exposing the browser chrome insets instead as @AmeliaBR mentioned (I think that's equivalent to this proposal) which might be easier to explain.

I would say that yes, any feature for adjusting to URL bar show/hide behavior should also include the keyboard and any other pop-up/pop-over browser widgets that cover part of the layout viewport. Example use case: if the UI consists mostly of a large text box, it's nice to make that fill most of the window. It's less nice if the box gets covered up by the keyboard you're using to type in it, and you end up with a scrolling text box inside a scrolling window.

Chrome on Android today resizes the ICB when the keyboard comes in. I think it's a rather regrettable decision since resizing the ICB can take a long time - it's a significant source of making the mobile web feel janky. In addition, it's not uncommon to tap on an editable only for the resized layout to now obscure the box you're trying to type into.

We've had success on ChromeOS using a model where the onscreen keyboard shrinks the visual viewport but leaves layout unchanged. Anecdotally this works much better: the user can still pan around the full viewport but the layout doesn't change at all when the keyboard comes up which works much better, especially on sites that didn't give much thought to onscreen keyboards. Unfortunately it's a difficult thing to bring to Android because of compat so we haven't been able to do it yet.

or exposing the browser chrome insets instead as @AmeliaBR mentioned (I think that's equivalent to this proposal) which might be easier to explain.

My only concern with that is: does the size of the inset change as the UA chrome changes size? If so, that feels like we would actually just be back at the initial behavior of vh units, and we wouldn’t have solved anything. But if they remain the same value even as UA chrome resizes, then I think that’s a good alternative to a vhc unit

though thinking about it, I'm curious how it would work. If there's 1 value that changes, then that's not good.

If there are 2 values (e.g. something like inset-ua-chrome-small and inset-ua-chrome-large), what would it take to get a full-height element?

For example:

height: 100vhc;

vs

height: calc(100vh - env(inset-ua-chrome-small) + env(inset-ua-chrome-large));

If I'm understanding the proposed env variable correctly - but it's entirely possible I'm not, though.

My recommendation would be the inset is a "collapsible height", i.e. how much the UA might expand as a result of scrolling.

In this case, this would be the full URL bar height, regardless of whether that's showing. So the full height would be:

height: calc(100vh - env(inset-collapsible-height))

Ah ok, yeah, that’s not too bad. Personally I would prefer to use a vhc unit (easier understand and teach, and if you have to use that value itself in a calc then it is much simpler than having to do nested calcs - unless you then put it in an custom property or something) but I wouldn’t be opposed to it if that’s what’s decided is better.

I also think you’ll find more developers using vhc (or equivalent) over vh so it would be nice if it were simple, but I have no hard evidence of that -- except for all the articles that say "avoid vh on mobile devices" :P

I was talking in slack with someone, and they proposed an alternative idea.

What if the behavior of vh could be determined in a dynamic way, similar to box-sizing? For example

.container {
  vh-sizing: expanded-viewport-height;
  height: 100vh;
}

with vh-sizing options potentially being something like

• collapsed-viewport-height (the current behavior of vh)
• expanded-viewport-height (the desired behavior of a vhc unit)
• exact-viewport-height (a unit that would always match the viewport exactly, even with keyboards or other UA chrome)

(all of these are just placeholder names)

With this pattern, the developer has options for all three use cases as noted by @AmeliaBR here, while also still being able to use vh in a backwards-compatible way with "progressive enhancement" (probably not the right word for it but I hope the idea comes across).

I thought it was a novel enough idea, and the backwards and forwards compatibility aspect of it made it interesting enough for me to add here for feedback as well.

My concern here is that as long as vh itself is defined to be too big when browser chrome is present, sites developed on desktop using emulation or just narrow window sizes will be designed using the existing viewport units, and not work correctly on mobile. Critical information will be beneath the "fold" in these cases. I agree that the vh unit needs to be stable as the user browses the page, but it seems to me that it would be safer (more consistent with the “avoid dataloss” principle) if the vh unit was tailored to the more conservative size, that corresponds to the size on initial page load. If we then also need a unit that corresponds to the fully-retracted UI's viewport size, then we can add an additional unit for that; but imo the default behavior should be the safer one if possible.

I agree that the vh unit needs to be stable as the user browses the page, but it seems to me that it would be safer (more consistent with the “avoid dataloss” principle) if the vh unit was tailored to the more conservative size, that corresponds to the size on initial page load. If we then also need a unit that corresponds to the fully-retracted UI's viewport size, then we can add an additional unit for that; but imo the default behavior should be the safer one if possible.

I agree; I think @bokand also mentioned that they (blink) would have preferred that to be the default here. Unfortunately, webkit adopted the opposite and now it's standard.

I think in an ideal world we could change the default behavior of vh, but then you have the potential to break the layout of tons of websites that relied on the old (current) size of vh. In other words, it isn't a 100% backwards compatible change.

Which is why I find the solution I listed above compelling, because it is 100% backwards compatible while also allowing new functionality for devs that opt-in to the new behavior.

The CSS Working Group just discussed Add vhc value.

I'm a fan of the new units, I think they make sense as spec'ed. I think the complaints I'm seeing about proliferation of CSS units are understandable, but they overlook the fact that today 100vh isn't useable on mobile without a bunch of additional work.

However, I don't think this problem can be solved in a satisfactory way without also dealing with the visible viewport when the on-screen keyboard appears. Today iOS browsers display the on-screen keyboard over the bottom of the viewport, and Android/Chrome shrinks the viewport to appear above the keyboard.

To provide a concrete example, if you were to define this CSS class using the proposed units:

.bottomQuarter {
  position: fixed;
  top: 75dvh;
  height: 25dvh;
  width: 100vw;
}

It would be hidden by the on-screen keyboard on iOS, and would appear above the keyboard on Android/Chrome. The same problem occurs if you define it using:

.bottomQuarter {
  position: fixed;
  bottom: 0;
  height: 25dvh;
  width: 100vw;
}

Or using units available today:

.bottomQuarterish {
  position: fixed;
  bottom: 0;
  height: 25vh;
  width: 100vw;
}

For additional background/sympathy: To workaround the browser chrome retraction and on-screen keyboard issues today I use the window.visualViewport.resize event (when supported, otherwise window.resize), and set CSS variables that are equivalent to dvh/dvb. I also detect viewport resizes, determine if they look like a "keyboard is showing/hiding" resize, then check whether an input or text area is active (to classify it as a keyboard resize); and then I compare a hidden 100vh element to the viewport height to determine if a --keyboard-height CSS var needs to be set on iOS so that elements that should appear above the keyboard need to be adjusted vertically.

In short, for this to be useful, we also need something like env(keyboard-height) and env(keyboard-active) variables.

There is the Virtual Keyboard API: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/VirtualKeyboardAPI/explainer.md

Thank you @fabb - I hadn't seen that. The Virtual Keyboard API proposal looks excellent to me.

My revised points are:

• The CSS developer ergonomics of positioning/sizing using virtual keyboard environment variables and the proposed browser chrome-aware viewport units should be considered. They will often be used together.
• Both proposals are limited in usefulness without the other.
• It should be stated that env(keyboard-inset-bottom), env(keyboard-inset-top) and env(keyboard-inset-height) exclude browser chrome.

I think my previous example can be used to illustrate this. Consider an element that occupies the bottom quarter of the visible viewport, and that remains visible above browser chrome, and above the virtual keyboard. And, the Virtual Keyboard proposal and viewport relative lengths are in place. And, we want it to work on browsers that don't support the 2 new proposals. The CSS would look like this:

.bottomQuarter {
  position: fixed;
  bottom: 0;
  bottom: env(keyboard-inset-bottom, 0px);
  width: 100vw;
  width: 100dvw;
  height: 25vh;
  height: calc(25dvh - env(keyboard-inset-height, 0px)/4);
}

I think this CSS is fine, but there's a case for adding environment variables for browser chrome offsets too. We will hopefully have environment variables for safe areas, virtual keyboard borders, and foldable device screens; for completeness it seems like collapsing browser chrome offsets should be added.

@tabatkins and I just committed the changes for this. We named the unit sv* (small viewport) and also added dv* (dynamic viewport) per #6113
The changes should show up in the ED soon: https://drafts.csswg.org/css-values-4/#viewport-relative-lengths

It is so good to se progress on this issue. Thank you!

The floating browser chrome of Safari 15 might introduce some new complexity. There is some ambiguity towards what could be considered the large and the small viewport. There are suddenly not two but three sizes that are of interest:

When browser chrome is floating:

• The height of the whole screen including the area behind and below the floating chrome (the largest area)
• The height of the area above the floating chrome (the smallest area)

When browser chrome is collapsed in the bottom:

• The height of the area above the collapsed browser chrome

I would expect the large viewport to be the area behind the floating chrome. If I were to use the units to size images to fill the entire screen, this is the area I want to fill, even though there is browser chrome floating above.

The small viewport though, would that be the area above the floating chrome (the smallest area), or the area when the browser chrome is collapsed at the bottom of the screen?

@johannesodland it seems the webkit team is currently toggling the value of safe-area-inset-bottom based on the browser chrome being collapsed or not.

https://twitter.com/jrigerl/status/1402042192160493569

@johannesodland it seems the webkit team is currently toggling the value of safe-area-inset-bottom based on the browser chrome being collapsed or not.

https://twitter.com/jrigerl/status/1402042192160493569

They seem to toggle both vh and safe-area-inset-bottom. These are the values I get on the iPhone 11 Pro simulator:

When browser chrome is floating
100vh = 768px
env(safe-area-inset-bottom) = 112px

When browser chrome is collapsed at bottom
100vh = 716px
env(safe-area-inset-bottom) = 0

There are essentially three sizes here:
768px – height behind the expanded/floating interface
712px – height when interface is retracted
656px – height above the expanded/floating interface

I can se a few issues here:

Fixed and stable
The spec declares that the large and the small viewports are fixed and stable. This is what mobile browsers have converged on for vh, but Safari 15 seems to reintroduce a dynamic vh that toggles when UA interfaces are expanded or retracted. This might cause issues with reflow, which was the reason browsers moved to a fixed vh unit in the first place: https://developers.google.com/web/updates/2016/12/url-bar-resizing

Defining the large viewport
The spec defines the large viewport as such: "... the large viewport size: the viewport sized assuming any UA interfaces that are dynamically expanded and retracted to be retracted. "

The issue here is that with Safari 15 you now get the largest viewport when the UA interfaces are expanded and floating above the viewport, not when it is retracted. It's the opposite of most current mobile browsers.

Defining the small viewport
One of the motivations for the small viewport is apparent in the example: "An element that is sized as height: 100svh, for example, will fill the screen perfectly, without any of its content being obscured, when all the dynamic UI elements of the UA are shown."

The smallest area where nothing is obscured is the area above the floating interface. If svh maps to this area you would be sure no content is obscured. But then you would have no way to reference the area with the UA interfaces retracted.

It could be more sensible to map svh to the height when the UA interfaces are retracted. This is the size that is most common when users are interacting with the page, and it also maps to document.documentElement.clientHeigh and height: 100% inside the root element. This would make content fit perfectly into the viewport when it is at it's smallest, but would not solve the "no content obscured" use case.

I think the spec might have to deal with floating UA interfaces. A also believe that is needs to address that the viewport can be at its largest when UA interfaces are visible, and the smallest when UA interfaces are retracted. This is the complete opposite of how it is in most browsers now.

Safari 15 seems to reintroduce a dynamic vh that toggles when UA interfaces are expanded or retracted

Since iOS Safari seems to have changed in a way that won't comply with these new spec changes and I just remembered that smart banners possibly affect viewport units, we might need some webkit eyes on this? @smfr?

@jensimmons could potentially also provide some insight as well?

I wanted to see for myself and verify what @johannesodland posted above, and here are my thoughts/observations (that are mostly just a rehash of what Johannes said above):

Using this page as a playground https://codepen.io/afrehner/full/MWmyZEq and having downloaded the XCode 13 beta in order to get access to the mobile version of iOS 15's Safari, I was able to take this video:

Observations:

• On page load, vh == lvh == (vh as currently defined)
• After ~1 second without any user interaction, vh == svh
• Scrolling downward, vh == svh
• Scrolling upward or tapping anywhere, vh == lvh

Essentially, Safari is now treating vh == dvh, and with that, all the good AND bad that comes with it. For example, notice the amount of layout shift when looking at section four; because all the content above it is using (d)vh, when the value of vh changes, four dramatically shifts where it is. This will only get worse the more content above you that uses the (d)vh value. We're now (kind of) back to where we were in the beginning, with vh being dynamic!

I think, more than anything, this emphasizes the importance of getting the s/d/l *vh units standardized soon, so that browsers vendors can experiment with their interfaces while allowing developers to build websites that won't be changing on them over time.

The CSS Working Group just discussed Values and Units L4, and agreed to the following:

• RESOLVED: "dynamic" viewport does indeed use units, not env()
• RESOLVED: Add lvh as explicit "large viewport" unit
• RESOLVED: vh/etc are deliberately UA-defined

Thank you to everyone expressing interest in and concern about what Safari for iOS15 is going to do. Yes, in the first few betas Safari was experimenting with changing vh to work like the new dvh unit. We are still working out the details of how the new Safari will work. Future betas will test other choices until we figure out what's best. It's too early to assume what you see in beta is what will ship in the fall.

@jensimmons Glad to see it's on the radar at the Safari team. I do hope that you will stay in touch and collaborate with the people behind other browsers to come to very consistent, standardised implementation in all browsers. This whole issue was created because some browsers showed unexpected behavior when using 100vh compared to others.

It would be a such a shame if all these years of struggle, discussions, finding hacks to make things work cross-browser and now finally introducing additional units to really fix the issue, if afterwards behavior still isn't the same across the board. That would be such a waste of time and effort. This should not really be about Apple's individual opinion but please make this a united decision. Only then these units have a real purpose, otherwise I'm afraid we might as well throw all of this in the bin, while we are so close to a solution. :)

When the issue/PR about the changes to vh is created, could you please link to it here? I would like to share some thoughts on it but want to wait until there's a focused discussion on it.

Thanks, and it's great to see this resolved!

Alright, officially published the 4-way v*/sv*/lv*/dv* spec at
https://www.w3.org/TR/css-values-4/#viewport-relative-lengths

Opened two issues for follow-up discussion: #6454 about enforcing v* as a static unit, and #6453 about the relationship with the actual initial containing block. We also have #6026 open about scrollbars.

The CSSWG resolved to close this issue and open new separate issues on anything else that needs to be discussed. It's been a great debate, but now this ticket has far too much going on, and it's not possible to keep up with the ideas. File new separate tickets about each detail / debate, and we can discuss there. As per the CSSWG's way of using issues. Thanks everyone!

To keep track of such issues, use [css-values-4] in the title, and put the css-values-4 label on it. Then you can see the list of what's being discussed about these units at: css-values-4 Current Work

And to talk about things that should be environment variables, use [css-env-1] in the issue title, and label it with css-env-1 so that it shows up here: css-env-1

And if you aren't sure whether it should be a unit or environment variable — put the more likely choice in the title, and label it with both labels.

See you in the other issues.