Repository navigation
[css-values-4] Restrictions on UA-default viewport units (unprefixed v*) #6454
Description
In #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?
Activity
frehner commentedon Jul 15, 2021
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
vhnot be left up to UA to define, and instead be aligned withsvhorlvh:Backwards compatibility
Given that, since 2015, the
vhunit 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
vhis 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 isvh == dvh, Browser3 isvh == lvh, and Browser4 issvh < 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; usel/d/s *vhinstead."Which leads me to my last point:
Sane/Good defaults
Given that
vhis 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 withsvhorlvh(but probably notdvh, 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
dvhcould be that unit? It seems to me likedvhalready fits the need by being explicitly a dynamic unit, and also by being constrained bysvh <= 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
dvhdoesn't fill their needs/requirements, perhaps another unit could be introduced that does?frehner commentedon Nov 2, 2021
I just discovered that webkit engineers appear to be working on the new
*vhunits already, which is excellent news.That said, are there any thoughts on my concerns about how the bare
vhunit 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 thatvh, as written, isn't ideal.Thanks 🙂
bramus commentedon Sep 19, 2022
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 commentedon Oct 27, 2023
Agenda+ to accept bramus's proposal to just say v* === lv*
cvrebert commentedon Nov 1, 2023
Will this involve noting in the spec that the
v*spellings are legacy/discouraged (for authors), in favor of the more-explicitlv*spellings?The redundancy, without context, would puzzle future software archaeologists.
css-meeting-bot commentedon Nov 1, 2023
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 unitsThe 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
[css-values-4] Pin v* to lv* due to interop, despite violating datalo…
fantasai commentedon Nov 22, 2023
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.
theres-waldo commentedon Jan 27, 2025
@fantasai could you say more about how lv* units cause dataloss?
bramus commentedon Jan 27, 2025
If you size something to 100lvh, part of it can be obstructed by the dynamic UA UI toolbars. It is not until those retract that the entire contents are visible in the viewport.