[css-values-4] Restrictions on UA-default viewport units (unprefixed v*)

[fantasai]

In https://github.com/w3c/csswg-drafts/issues/4329 we added three sets of more explicit viewport units--the small, large, and dynamic viewport units sv*, lv*, and dv*--and left the unprefixed viewport units to be UA-defined.

The current wording of the spec is:

The UA-default viewport-percentage units (v*) are defined with respect to a UA-defined UA-default viewport size, which for any given document should be equivalent to the large viewport size, small viewport size, or some intermediary size.

Are there any other restrictions we should be adding to the UA's choices here (besides svh <= vh <= lvh)?

For example, the sv and lv units are explicitly not dynamic (this is their whole purpose). Should v* be likewise restricted to a non-dynamic interpretation, so that components using them are not resized as one scrolls?

[frehner]

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?

[frehner]

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 🙂

[bramus]

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.

[tabatkins]

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

[cvrebert]

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.

[css-meeting-bot]

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

The full IRC log of that discussion

<dael> TabAtkins: A while back when defining the set of viewport units there was a question what old version should be. The plain ones
<dael> TabAtkins: Defined as undefined but have to between small and large. I believe at the time UAs were inconsistent
<dael> TabAtkins: Now the test we performed seem to show unprefixed is large viewport is where people converged. Would like to spec that
<dael> astearns: Comments? Concerns?
<dael> astearns: I see some research. Do we have WPT?
<dael> TabAtkins: I believe research was based on WPT but we can make sure to cover
<dael> TabAtkins: Issue is difference between units only shows on mobile, but WPT coverage of mobile is underdeveloped. There is work on that
<dael> astearns: Prop: Define how new and old viewport units interact and that old units are eq. to large viewport units
<dael> astearns: Obj?
<dael> RESOLVED: Define how new and old viewport units interact and that old units are eq. to large viewport units

[fantasai]

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.