Thanks for creating this issue! I hope I'm not overstepping here, but I would like to share some of my thoughts around this proposal.

Due to the three reasons listed below, I would suggest that vh not be left up to UA to define, and instead be aligned with svh or lvh:

Backwards compatibility

Given that, since 2015, the vh unit has been a stable and unchanging unit, it seems like allowing it to potentially become a dynamic unit again could introduce a LOT of issues and bugs in existing websites. It was for this reason that I originally proposed a new unit.

Browser inconsistency

If vh is allowed to be a UA-defined size, does that mean that it essentially is allowed to be different things on different browsers?

For example, Browser1 could have it be vh == svh, Browser2 is vh == dvh, Browser3 is vh == lvh, and Browser4 is svh < vh < lvh?

If that's the case, I honestly can't think of a time that a web developer would ever want that experience. Working with browser inconsistencies is bad enough; working with things that are intentionally inconsistent would, I think, essentially lead all web developers to just throw their hands in the air and say "There is never a case that you should use vh; use l/d/s *vh instead."

Which leads me to my last point:

Sane/Good defaults

Given that vh is the much older and more fully adopted unit already, I think it's important that it remain a good default. I don't really care if it aligns with svh or lvh (but probably not dvh, given the point above about Backwards Compatibility), but I think it would be unwise for this widely used and documented and taught unit to suddenly turn into something that could be inconsistent across browsers.

A Potential Counter Proposal

With all that said, I DO still think it would be nice to give browser vendors a unit to play around with, and web developers a unit that always matches exactly; do you think dvh could be that unit? It seems to me like dvh already fits the need by being explicitly a dynamic unit, and also by being constrained by svh <= dvh <= lvh. It also allows developers to opt-in to the dynamic value, instead of having a static value suddenly changed underneath them.

However, if dvh doesn't fill their needs/requirements, perhaps another unit could be introduced that does?

I just discovered that webkit engineers appear to be working on the new *vh units already, which is excellent news.

That said, are there any thoughts on my concerns about how the bare vh unit itself is specced, as I outlined in the comment above? I would hate for browser engineers to work on the spec and then potentially have to change it later if it is determined that vh, as written, isn't ideal.

Thanks 🙂

As part of the Interop 2022 Viewport Investigation Effort we noticed that all tested User Agents use the Large Viewport as the UA-Default Viewport.

We think it would be feasible to update the spec updated on this matter, to state that the UA-default viewport size (and its units) is an alias for the large viewport size.

Agenda+ to accept bramus's proposal to just say v* === lv*

Will this involve noting in the spec that the v* spellings are legacy/discouraged (for authors), in favor of the more-explicit lv* spellings?
The redundancy, without context, would puzzle future software archaeologists.

The CSS Working Group just discussed [css-values-4] Restrictions on UA-default viewport units (unprefixed v*), and agreed to the following:

• RESOLVED: Define how new and old viewport units interact and that old units are eq. to large viewport units

For the record, I'm very disappointed that this didn't end up mapping to the small viewport units, because we do have a principle to avoid dataloss by default, and the lv* units can and do cause dataloss in many cases.