W3C home > Mailing lists > Public > public-css-archive@w3.org > July 2021

Re: [csswg-drafts] [css-values-4] Restrictions on UA-default viewport units (unprefixed v*) (#6454)

From: Anthony Frehner via GitHub <sysbot+gh@w3.org>
Date: Thu, 15 Jul 2021 15:50:39 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-880808709-1626364237-sysbot+gh@w3.org>
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](https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-542420036), 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](https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-545522192).

## 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`, and Browser3 is `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? 

-- 
GitHub Notification of comment by frehner
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6454#issuecomment-880808709 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 15 July 2021 15:50:41 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:39 UTC