search

w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.5k stars 666 forks source link

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

Closed frehner closed 3 years ago

frehner commented 5 years ago

Latest info

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

See https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-863677668 and https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-880040513 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 https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-542420036

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 1 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. :)

jensimmons commented 3 years ago

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!

jensimmons commented 3 years ago

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: https://github.com/w3c/csswg-drafts/labels/css-values-4

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: https://github.com/w3c/csswg-drafts/labels/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.