[css-values-4] Add vhc value

Latest info

Added lvh, svh, dvh, lvw, svw, and dvw units.

See #4329 (comment) and #4329 (comment) for more details. 🎉

Original content below:

Background

vh is defined as Equal to 1% of the height of the initial containing block. Perhaps the current behaviour^{1 2} could also be defined as

Equal to 1% of the height of the initial containing block with user agent chrome minimized.

In other words, on devices where the browser chrome changes size (e.g. mobile devices), 100vh is actually larger than the viewport when the browser chrome is maximized, and thus overflows.

A brief history of the vh unit is outlined here #4329 (comment)

Proposal

vhc (c = "with chrome", but it could be something else) could be defined as

Equal to 1% of the height of the initial containing block, with user agent chrome maximized

On devices without a changing chrome size (e.g. desktop devices), 1vh === 1vhc.

Advantages and Drawbacks

Pros and Cons list for each proposal

Original content of this section:

A drawback of vh units is that content will be cut off when (1) you load a page and (2) when you scroll upwards, while the content fits when you scroll down and the chrome is minimized.

The vhc unit would be the inverse: content would fit the page when (1) you load the page and (2) when you scroll upwards, but you would see additional content (or whitespace, depending on the implementation) when the chrome is minimized.

It also would provide a better experience than vh for games and other full-screen content that doesn't or shouldn't scroll at all.

In the end, this proposal does not completely solve the issue of 1vh needing to be different values at different times. However, it does at least give the developer a choice in which value that they want to use.

(For what it's worth, my personal preference is that I would end up using vhc units for responsive designs, because I would rather have additional content visible or some whitespace added, rather than have content cut off and not visible.)

Alternative Proposals

And a breakdown of the pros and cons of each proposal so far

Current Workarounds

As it stands, web developers that want to have a full-height website are either reliant on javascript ^{1 2 3} to get vh units to not cut off content, or just tend to avoid ¹ using vh units altogether.

Unrelated

This is my first time proposing, so if I did something wrong or need to improve something please let me know! Thank you for your patience. :)

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?

@jensimmons

@jensimmons could potentially also provide some insight as well?

@johannesodland

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:

iOS15-vh.mov

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

The full IRC log of that discussion

<fantasai> Topic: Values and Units L4
<TabAtkins> ScribeNick: TabAtkins
<fantasai> github: https://github.com//issues/4329#issuecomment-863677668
<TabAtkins> fantasai: Tab and I comitted the changes for our earlier resolution on these joint issues (this and next)
<fantasai> https://github.com//issues/6113
<Rossen_> q
<TabAtkins> fantasai: we resolved to add viewport units to represent the "small" and "dynamic" viewport
<TabAtkins> fantasai: there are a couple open qustions still
<TabAtkins> fantasai: One was whether dynamic should be a unit or an env()
<TabAtkins> fantasai: We went for unit based on comments from Rachel Andrews that it would be easier to teach
<TabAtkins> fantasai: Main reason for env() was to deliberately make it more awkward to use.
<TabAtkins> fantasai: Right now tho, the draft is using units; we can reopen that discussion if people wish
<TabAtkins> fantasai: Other question is we have an unprefixed set of units (vw/etc) and two prefixed sets (svw/etc, dvw/etc)
<TabAtkins> fantasai: Do we want an explicit set of "larger" prefixed units for symmetry?
<TabAtkins> fantasai: And if we do that, should we allow the unprefixed values to do something smarter? Right now they're the larger viewport, but this causes some troubles and browsers might want to do something smarter.
<TabAtkins> fantasai: So do we want to give CSS some flexibility for the unprefixed units?
<TabAtkins> fantasai: So first quesiton to tackle: anyone want us to switch the dynamic units to being an env()?
<TabAtkins> jensimmons: I think it works well as a unit. Authors will need and use it, and having it be the same as the other units will make it much easier to use.
<florian> +1
<miriam> +1
<rachelandrew> +1
<TabAtkins> Rossen_: Do we ahve a particularly well-defined guidance on how and when to add value types vs env()? It woudl be unfortunate if we end up in a situation where scrollbar-width is in an env() but viewport-width is in a unit, etc
<TabAtkins> fantasai: We don't have this written down, but the basic principle is if you're likely to want multiples of this other than 1.
<TabAtkins> fantasai: Like for safe-area-inset, you don't want 30% of it, or 5x that.
<TabAtkins> fantasai: You might add some more length to it, some extra px or something, but very unlikely to want to multiply it by a number.
<TabAtkins> fantasai: But for viewport units it's very common to want 50vh/etc, so it makes more sense to be a unit where it's easier to do that
<TabAtkins> Rossen_: I can see how this could make sense from a usage pov
<TabAtkins> Rossen_: At the same time I could argue the inset should be a unit regardless of whether you'd want it to be x1 or not
<TabAtkins> florian: Other factor is if the value depends on where you are in the tree, it must be a unit. If it doesn't, either works.
<TabAtkins> florian: For example, width of scrollbars cannot be an env() because it changes based on the unit you're applying it to.
<TabAtkins> emilio: Having units depend on computed values of properties is kinda sketchy...
<TabAtkins> florian: Sure, but still like having font-size expressed in an env() doesn't make sense, so you need em
<bmathwig> width of scrollbars can't change depending on element, it's fixed in most UA implementations
<TabAtkins> emilio: Sure, tho there's only two scrollbar widths. Could still be done as two env()s
<TabAtkins> plinss: I don't feel too strongly, but I'm a little concerned about proliferation of units.
<florian> bmathwig, see https://drafts.csswg.org/css-scrollbars/#scrollbar-width
<TabAtkins> plinss: If the non-unit syntax ends up unwieldy, we can work on that.
<TabAtkins> Rossen_: Basically same for me. I'd also like us to formulate a more general reasoning for when to use units vs env()
<bmathwig> auto | thin | none only applies to classical scrollbars and not overlay scrollbars that have zero-width in layout computations
<TabAtkins> Rossen_: But overall I don't object.
<bmathwig> Blink is moving towards overlay scrollbars on Windows in the next few months
<TabAtkins> fantasai: Okay so it sounds like we should resolve on dvh being units
<fantasai> bmathwig, that doesn't change the matter of the width of the scrollbar, only how much space it takes up in layout
<TabAtkins> RESOLVED: "dynamic" viewport does indeed use units, not env()
<TabAtkins> fantasai: So next is about unprefixed units.
<TabAtkins> fantasai: Do we want an explicit large-prefixed set to go with the others?
<TabAtkins> jensimmons: been a lot of convo on WK team last week about how these work
<TabAtkins> jensimmons: We feel very strongly there should be an lvh unit
<TabAtkins> jensimmons: And the vh unit should no longer be defined as longest length; it should instead be something more flexible that the UA can decide on based on what they're doing with their particular browser
<bmathwig> fantasai, very true
<lea> I'm all up for making vw/vh more useful, but how web compatible is this change?
<TabAtkins> florian: I see why you'd want the flexibility for this, to provide best UX possible, I'm concerned about variance in behavior that would cause content to be off-screen in one browser, etc.
<TabAtkins> fantasai: tbf that's already happening today
<TabAtkins> jensimmons: Lea made a comment about webcompat, that's absolutely a concern
<lea> q?
<TabAtkins> jensimmons: I think having this be flexible so UA can make the best decision to present the fewest compat problems
<TabAtkins> jensimmons: And by giving authors the explicit lvh and others let them choose the right one for their website
<florian> I'm sold :)
<lea> +1 for this change from me
<TabAtkins> jensimmons: But browsers may need flexibility to redefine that vh itself based on individual pages
<fantasai> +1 from me also
<TabAtkins> emilio: I think any change to vh should probably be a [...? missed]
<TabAtkins> emilio: I think we want a definition in the spec we can implement interoperably
<emilio> s/be a ?/ consider compat, but...
<TabAtkins> fantasai: So I think we have agreement to add "large" viewport units, make vh/etc ambiguous at the moment (and gradually make it clear what this actually means)
<TabAtkins> fantasai: So for now we say it's UA-defined and it must fall in the range of svh and lvh
<TabAtkins> florian: Also a note that if any UA uses the flexibility to make it something other than the three explicit ones, come back to the group and spec it
<TabAtkins> emilio: Can we file an issue to explore the compat of vh/etc?
<TabAtkins> fantasai: We should also have an issue about what is the ICB in these cases, and that's probably the same
<florian> s/and spec it/so that we can see if it is something we could spec/
<fantasai> s/probably the same/probably should be the same as the unprefixed units/
<TabAtkins> jensimmons: I noticed in the discussion there was some discussion about the "l" standing for "layout viewport", but I like it better to be "longest"
<florian> +1 to s/d/l as the naming
<TabAtkins> fantasai: Earlier we were thinking we'd use an "l" prefix for the dynamic one. Now we're gonna do small/large for s/l, or short/long, whichever you prefer to talk about
<TabAtkins> RESOLVED: Add lvh as explicit "large viewport" unit
<TabAtkins> astearns: So second is about redefining vh
<TabAtkins> fantasai: Currently the spec is actually extremely vague
<TabAtkins> fantasai: it just says "it's the size of the viewport"
<TabAtkins> fantasai: So the resolution here would be to maintain the ambiguity
<TabAtkins> florian: Maintain ambiguity or explicitly say it's UA-defined?
<TabAtkins> fantasai: I'm fine with either
<TabAtkins> florian: I'd prefer UA-defined with the note i said earlier
<TabAtkins> florian: About UAs reporting to the WG if they do somethign creative
<TabAtkins> astearns: Any objections?
<fantasai> scribe+ TabAtkins
<TabAtkins> RESOLVED: vh/etc are deliberately UA-defined
<TabAtkins> fantasai: That should be it for this issue, tho we need to open that issue about the nuances of vh
<TabAtkins> astearns: I'd encourage people to file new issues for any further discussions, these issues got long and intertwined and it'll be easier with new issues

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

@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!

[css-values-4] Add lv* units explicitly for large viewport size. #4329

[css-values-4] Clarify guidance on categorization of interface change…

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.

[css-values-4] Rephrase requirements into a list for easier reading. #…

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.

[css-values-4] Fix inverted assignment of A and B. #4329

Navigation Menu

Repository navigation

[css-values-4] Add vhc value #4329

Latest info

Background

Proposal

Advantages and Drawbacks

Alternative Proposals

Current Workarounds

Unrelated

93 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[css-values-4] Add vhc value #4329

Description

Latest info

Background

Proposal

Advantages and Drawbacks

Alternative Proposals

Current Workarounds

Unrelated

Activity

frehner commented on Oct 9, 2019

fantasai commented on Oct 10, 2019

rachelandrew commented on Oct 10, 2019

frehner commented on Oct 10, 2019

rachelandrew commented on Oct 10, 2019

frehner commented on Oct 10, 2019

tabatkins commented on Oct 15, 2019

tabatkins commented on Oct 15, 2019

AmeliaBR commented on Oct 15, 2019

frehner commented on Oct 15, 2019

tabatkins commented on Oct 15, 2019

93 remaining items

frehner commented on Jul 3, 2021

frehner commented on Jul 7, 2021

css-meeting-bot commented on Jul 14, 2021

jensimmons commented on Jul 14, 2021

TimmiX88 commented on Jul 14, 2021

frehner commented on Jul 14, 2021

fantasai commented on Jul 15, 2021

jensimmons commented on Jul 23, 2021

jensimmons commented on Jul 23, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions