[csswg-drafts] [css-values-4] Add vvh+vvw values (#6113)

brunoais has just created a new issue for https://github.com/w3c/csswg-drafts:

==  [css-values-4] Add vvh+vvw values ==
Note: Contents based on the [`vhc` proposal](#4329)
## 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 **behavior** [1](https://bugs.webkit.org/show_bug.cgi?id=141832) [2](https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/BK0oHURgmJ4) could also be defined as

> Equal to 1% of the height of the initial containing block _with browser overlays hidden or collapsed_.

In other words, on devices with a browser's chrome or any other variable sized overlay (e.g. mobile devices), `100vh` is actually larger than the viewport when the browser chrome is maximized, and thus overflows, leading to scroll bars to appear.

A brief history of the `vh` unit is outlined here [#4329 (comment)](https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-542420036)

Additionally, browsers may come in the future where the chrome or any other collapsible browser overlay may be placed on the sides. For example, a browser that, in landscape, shows the chrome on the short side or a browser that shows a helper overlay on the side while the navigation is on the top overlay. `vvw` is meant to handle when such possible cases comes to light. If anything, `vvw` will bring consistency when using `vvh` to have a `vvw` counterpart.

## Proposal

`vvh` (as "Visual Viewport height", but it could be something else) defined as:

> Equal to 1% of the height of the visual containing block of the user agent

In other words: 1% of the height of the user-visible part of the web page.

And it's width counterpart:  
`vvw` (as "Visual Viewport width", but it could be something else) defined as:

> Equal to 1% of the height of the visual containing block of the user agent

In other words: 1% of the width of the user-visible part of the web page.

On devices without a changing chrome size (e.g. Most desktop devices), `1vh === 1vvh`.  
On devices without a changing chrome size (e.g. Most desktop devices), `1vw === 1vvw`.

## Advantages and Drawbacks

[Pros and Cons list for proposals to `vhc` which similarly apply to `vvh` ](https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-547551485)

`vhc` isn't enough to solve the problems at hand because it doesn't specify a percentage size for the whole currently visible page. If using `vhc` and `vh` together:


- When the chrome is open
  - if using `vhc` → Size is right
  - if using `vh` → Content overflows and scroll bars may appear because of it.
- When the chrome is closed
  - if using `vhc` → A gap in content will appear or elements meant to be placed at edges will be placed elsewhere
  - if using `vh` → Size is right

Intermediate verdict: Seems like js will be needed to swap between those two.
However: browser chrome in Chrome and Firefox (as 2 examples) don't only have open and close. They progressively go between those two.

In order to support those intermediate states, without `vvh`, positioning will have to be done using javascript leaving `vhc` and `vh` scarcely used.

`vvh` solves by allowing to place the content based on the whole visible part of the web page without the need for js work arounds.

Additionally, the same way as the usage of variables is not an alternative to `vhc`, it is also not a viable alternative to `vvh`

And [a breakdown](https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-547551485) 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](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) to get `vh` units to not cut off content, or just tend to avoid [1](https://chanind.github.io/javascript/2019/09/28/avoid-100vh-on-mobile-web.html) using `vh` units altogether.

## Alternatives

The [vh-sizing](https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-543344105), in my opinion, is the only alternative I know to be a viable towards `vvh`

## Assurances/Examples

An element with the following CSS computed:

```
margin: 0;
padding: 0;
border: 0;
height: 100vvh;
width: 100vvw;
position: fixed;
top: 0;
left: 0;
```
Will:
1. Cover the whole viewport without any pixels in excess or at fault.
2. Must not be the cause for scroll bars to appear.

With `vhc`, when the chrome is closed, a gap would appear somewhere on the top or the bottom of the page or centered elements wouldn't actually be centered, etc... It still would require javascript to solve a CSS problem.

## Unrelated

This is my first time proposing, so feel free to help me improve this proposal! 
Thank you for your patience.




Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6113 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 17 March 2021 20:25:53 UTC