W3C home > Mailing lists > Public > public-css-archive@w3.org > September 2019

[csswg-drafts] [css-values] Add `vhc` value (#4329)

From: Anthony Frehner via GitHub <sysbot+gh@w3.org>
Date: Wed, 18 Sep 2019 18:00:05 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-495372962-1568829603-sysbot+gh@w3.org>
frehner has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-values] Add `vhc` value ==
## Background

`vh` is [defined](https://drafts.csswg.org/css-values-4/#viewport-relative-lengths) as `Equal to 1% of the height of the initial containing block.` Perhaps the current **behaviour**<sup> [1](https://bugs.webkit.org/show_bug.cgi?id=141832) [2](https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/BK0oHURgmJ4)</sup> could also be defined as
>Equal to 1% of the height of the initial containing block _with browser 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 visible, and thus overflows.

## 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 browser chrome

On devices without a changing chrome size (e.g. desktop devices), `1vh === 1vhc`.

## Advantages and Drawbacks

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

## Current Workarounds

As it stands, web developers that want to have a full-height website are either reliant on javascript <sup> [1](https://css-tricks.com/the-trick-to-viewport-units-on-mobile/) [2](https://stackoverflow.com/a/43575432) [3](https://github.com/mvasin/react-div-100vh)</sup> to get `vh` units to not cut off content, or just tend to avoid 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. :)

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4329 using your GitHub account
Received on Wednesday, 18 September 2019 18:00:07 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:53 UTC