Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/w3c/csswg-drafts/issues/6113 below:

[css-values-4] Add lvh+lvw values · Issue #6113 · w3c/csswg-drafts · GitHub

Note: Contents based on the vhc proposal

vh is defined as Equal to 1% of the height of the initial containing block. Perhaps the current behavior 1 2 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)

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. lvw is meant to handle when such possible cases comes to light. If anything, lvw will bring consistency when using lvh to have a lvw counterpart.

lvh (as "Layout Viewport height", but it could be something else) defined as:

Equal to 1% of the height of the layout viewport of the user agent

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

And it's width counterpart:
lvw (as "Layout Viewport width", but it could be something else) defined as:

Equal to 1% of the width of the layout viewport of the user agent

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

If an infinite cycle exist in the calculation such that:

1. Before finishing the calculation for the page, and scroll bars are auto and they would be needed.
2. Due to dynamic units, after the calculations, no scroll bars necessary anymore.
3. After readjusting to not requiring scroll bars, a resize forces back the need for scroll bars again.

This is how MUST be solved:

1. Add scroll bars vertically.
2. Problem solved?
   1. If yes, keep the scroll bar
   2. layout the rest.
3. Add a horizontal scroll bar
4. Problem solved?
   1. If yes, keep the scroll bars
   2. layout the rest.

If 1 or 3 is used and the UA has a console, the browser, by default, SHOULD create a CSS warning explaining the problem which includes the tags that lead for the need to add the scroll bars.
However, the browser MAY provide means to turn it off and also MAY only warn once per conflict per page load.
The way such message expresses the need is up to the UA itself. The UA MAY add more information as it sees fit.

The UA is responsible for choosing how often to update the calculated value of the unit and the refresh rate for the visual viewport.
The UA SHOULD keep into account the hardware capabilities and power settings of the host machine.
The UA MAY provide options for the user to select how smooth he wants the experience to be through user options. It is up for the UA to decide what options the users have access to and how they are presented.
The UA MAY cache how the elements look with and without such overlays, relevant in-betweens, etc...

For example: on an Android device which has power settings, the UA can decide to slow down the refresh rate to save battery.

Pros and Cons list for proposals to vhc which similarly apply to lvh

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 lvh, positioning will have to be done using javascript leaving vhc and vh scarcely used.

lvh 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 lvh

And a breakdown of the pros and cons of each proposal so far

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.

The vh-sizing, in my opinion, is the only alternative I know to be a viable towards lvh

With zoom at 1 (100%) (I.e. no pinch zooming applied or pinch zooming not available)
An element with the following CSS computed:

margin: 0;
padding: 0;
border: 0;
height: 100lvh;
width: 100lvw;
position: fixed;
top: 0;
left: 0;

Ensures that:

1. Element covers the whole visual viewport without any pixels in excess or at fault.
2. Must not be the cause for scroll bars to appear.
3. If scroll bars already exist, the lvh will take the scroll bars size into account

However, the user may zoom in and then scroll (or pan) to see the whole intended content with a larger visual size in his device screen.

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.

With zoom at 1 (100%) (I.e. no pinch zooming applied or pinch zooming not available)
An element with the following CSS computed:

margin: 0;
padding: 0;
border: 0;
max-height: 100lvh;
max-width: 100lvw;
position: fixed;
top: 100lvh;
transform:translatey(-100%);

Ensures that:

1. Element will always be at the bottom of the viewport and fully visible.
2. Its position must not be the cause for scroll bars to appear.
3. If scroll bars already exist, the lvh will take the scroll bars size into account.

For this specific case, I do recommend:

top: auto;
bottom: 0;
transform:initial;

Instead of the above but I believe it is a viable way of exemplifying.

On devices without a changing chrome size (e.g. Most desktop devices), scroll bars hidden and with viewport set as width=device-width these two are always true:

1. 1vh === 1lvh
2. 1vw === 1lvw

If you specify <html> in CSS as:

html {
  margin: 0;
  padding: 0;
  border: 0;
  height: 100lvh;
  width: 100lvw;
}

The HTML tag will behave the same as <html> currently does by default when the viewport is specified as:
<meta name="viewport" content="width=device-width,minimum-scale=1,maximum-scale=1"> and no scroll bars are necessary

With zoom at 1 (100%) (I.e. no pinch zooming applied or pinch zooming not available)
An element with the following CSS computed:

margin: 0;
margin-bottom: 1px;
padding: 0;
border: 0;
height: 100lvh;
width: 100lvw;
position: fixed;
top: 0;
left: 0;

Ensures that:

1. Element covers the whole visual viewport without any pixels in excess or at fault.
2. Must be the cause for automatic vertical scroll bars to appear
3. If this is the only item that cause automatic scroll bars to appear, the scroll bars that appear due to this margin, can only scroll by 1px.
4. If on the root: overflow-y is either hidden or clip, From the user's perspective, there's no visual difference wether margin-bottom is 0 (previous example) or 1px.

However, the user may zoom in and then scroll (or pan) to see the whole intended content with a larger visual size in his device screen.

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

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.3