Skip to content

Commit

Permalink
[css-values-4] Define small and dynamic variants of viewport-relative…
Browse files Browse the repository at this point in the history 
… units. #4329 #6113

https://lists.w3.org/Archives/Public/www-style/2020Feb/0007.html
https://lists.w3.org/Archives/Public/www-style/2021May/0010.html
  • Loading branch information
@fantasai
fantasai committed Jun 18, 2021
1 parent 76c5c7f commit 0f78ba4
Showing 1 changed file with 185 additions and 17 deletions.
202 changes: 185 additions & 17 deletions css-values-4/Overview.bs
View file
Original file line number Diff line number Diff line change
Expand Up @@ -544,11 +544,9 @@ CSS-wide keywords: ''initial'', ''inherit'' and ''unset''</h4>
All of these keywords are normatively defined in the Cascade module. [[!CSS3CASCADE]]

<wpt>
css/css-values/initial-background-color.html
css/css-multicol/multicol-inherit-002.xht
css/css-multicol/multicol-rule-color-inherit-001.xht
css/css-multicol/multicol-rule-color-inherit-002.xht
css/css-values/unset-value-storage.html
css/CSS2/values/units-008.xht
</wpt>

Expand Down Expand Up @@ -1737,25 +1735,158 @@ Font-relative Lengths: the ''em'', ''ex'', ''cap'', ''ch'', ''ic'', ''rem'', ''l
-->

<h4 id="viewport-relative-lengths">
Viewport-percentage Lengths: the ''vw'', ''vh'', ''vi'', ''vb'', ''vmin'', ''vmax'' units</h4>
Viewport-percentage Lengths: the ''*vw'', ''*vh'', ''*vi'', ''*vb'', ''*vmin'', ''*vmax'' units</h4>

ISSUE: <img src="../construction.gif" alt="" style="float: right">
This section is <strong>UNDER CONSTRUCTION</strong>.
Please use <a href="https://www.w3.org/TR/css-values-3/">CSS Values and Units Level 3</a>
as an implementation reference for now.

The <dfn export>viewport-percentage lengths</dfn> are relative to the size of the
<a href="https://www.w3.org/TR/CSS21/visudet.html#containing-block-details">initial containing block</a>.
When the height or width of the initial containing block is changed,
they are scaled accordingly.
However, when the value of 'overflow' on the root element is ''overflow/auto'',
any scroll bars are assumed not to exist.
<span class='note'>Note that the initial containing block's size is affected by the presence of scrollbars on the viewport.</span>

ISSUE(1766): Level 3 assumes scrollbars never exist because it was hard to implement. This is making authors unhappy.
<h5 id="viewport-variants" class="no-toc">
The Large, Small, and Dynamic Viewport Sizes</h5>

There are three variants of the [=viewport-percentage length=] units,
corresponding to three (possibly identical) notions of the viewport size.

<dl export>
<dt>large viewport
<dd>
The <dfn export>large viewport-percentage units</dfn>
are defined with respect to the <dfn export>large viewport size</dfn>:
the viewport sized assuming
any UA interfaces that are dynamically expanded and retracted
to be retracted.
This allows authors to size content
such that it is guaranteed to fill the viewport,
noting that such content might be hidden behind such interfaces
when they are expanded.

The sizes of the [=large viewport-percentage units=] are fixed
(and therefore stable) unless the viewport itself is resized.

<div class=example>
For example, on phones,
where screen real-estate is at a premium,
browsers will often hide part or all of the title and address bar
once the user starts scrolling the page.
The [=large viewport-percentage units=] are sized relative to
this larger everything-retracted space,
so content using these units will fill the entire visible page
when these UI elements are hidden.
However, when these retractable elements are shown,
they can obscure content
that is sized or positioned using these units.
</div>

<dt>small viewport
<dd>
The <dfn export>small viewport-percentage units</dfn>
are defined with respect to the <dfn export>small viewport size</dfn>:
the viewport sized assuming
any UA interfaces that are dynamically expanded and retracted
to be expanded.
This allows authors to size content
such that it can fit within the viewport
even when such interfaces are present,
noting that such content might not fill the viewport
when such interfaces are retracted.

The sizes of the [=small viewport-percentage units=] are fixed
(and therefore stable) unless the viewport itself is resized.

<div class=example>
An element that is sized as ''height: 100svh'', for example,
will fill the screen perfectly,
without any of its content being obscured,
when all the dynamic UI elements of the UA are shown.

Once those UI elements start being hidden, however,
there will be extra space around the element.
The [=small viewport-percentage units=] units are thus “safer” in general,
but might not produce the most attractive layout
once the user starts interacting with the page.
</div>

<dt>dynamic viewport
<dd>
The <dfn export>dynamic viewport-percentage units</dfn>
are defined with respect to the <dfn export>dynamic viewport size</dfn>:
the viewport sized
with dynamic consideration of any UA interfaces
that are dynamically expanded and retracted.
This allows authors to size content
such that it can exactly fit within the viewport
whether or not such interfaces are present.

The sizes of the [=dynamic viewport-percentage units=]
<em>are not stable</em>
even while the viewport itself is unchanged.
Using these units can cause content
to resize e.g. while the user scrolls the page.
Depending on usage,
this can be disturbing to the user
and/or costly in terms of performance.

The UA is not required to animate the [=dynamic viewport-percentage units=]
while expanding and retracting any relevant interfaces,
and may instead calculate the units
as if the relevant interface was fully expanded or retracted
during the UI animation.
(It is recommended that UAs assume the fully-retracted size
for this duration.)
</dl>

Whether the expansion/retraction of a particular interface
changes the sizes of all of the [=viewport-percentage lengths=]
(and the [=initial containing block=])
simultaneously
or contributes to the differences between
the [=large viewport size=] and [=small viewport size=]
is largely UA-dependent.
However,
UAs <em>must</em> categorize as the latter
any changes in interface that happen as a result of scrolling
or other frequent actions that would disturb the user
if they resulted in substantial layout changes.
Additionally,
UAs may have some dynamically-shown interfaces which intentionally overlay content
and do not cause any shifts in layout;
typically on-screen keyboards will fit into this category.

For [=paged media=], the exact definition of the viewport-percentage lengths
is deferred to [[!CSS3PAGE]].
However, in the typical case of all pages being the same size,
they are sized relative to the [=page area=].

In all cases, scrollbars are assumed not to exist.
<span class='note'>Note however that the [=initial containing block=]'s size
<em>is</em> affected by the presence of scrollbars on the viewport.</span>

ISSUE: <a href="https://www.w3.org/TR/css-values-3/#viewport-relative-lengths">Level 3 assumes scrollbars never exist</a> because it was hard to implement
and only Firefox bothered to do so.
This is <a href="https://github.com/w3c/csswg-drafts/issues/1766#issuecomment-460470368">making authors unhappy</a>.
Can we improve here?

<h5 id="viewport-relative-units" class="no-toc">
The Various Viewport-relative Units</h5>

The [=viewport-percentage length=] units are:

<dl export dfn-type=value dfn-for="<length>">
<dt><dfn id="vw" lt="vw">vw unit</dfn>
<dt><dfn lt="vw">vw unit</dfn>
<dt><dfn lt="svw">svw unit</dfn>
<dt><dfn lt="dvw">dvw unit</dfn>
<dd>
Equal to 1% of the width of the initial containing block.
Equal to 1% of the width of the
[=large viewport size=],
[=small viewport size=],
and [=dynamic viewport size=],
respectively.

<div class="example">
In the example below, if the width of the viewport is 200mm,
Expand All @@ -1765,25 +1896,49 @@ Viewport-percentage Lengths: the ''vw'', ''vh'', ''vi'', ''vb'', ''vmin'', ''vma
<pre>h1 { font-size: 8vw }</pre>
</div>

<dt><dfn id="vh" lt="vh">vh unit</dfn>
<dt><dfn lt="vh">vh unit</dfn>
<dt><dfn lt="svh">svh unit</dfn>
<dt><dfn lt="dvh">dvh unit</dfn>
<dd>
Equal to 1% of the height of the initial containing block.
Equal to 1% of the height of the
[=large viewport size=],
[=small viewport size=],
and [=dynamic viewport size=],
respectively.

<dt><dfn lt=vi>vi unit</dfn>
<dt><dfn lt=svi>svi unit</dfn>
<dt><dfn lt=dvi>dvi unit</dfn>
<dd>
Equal to 1% of the size of the initial containing block
Equal to 1% of the size of the
[=large viewport size=],
[=small viewport size=],
and [=dynamic viewport size=]
(respectively)
in the direction of the root element's inline axis.

<dt><dfn lt=vb>vb unit</dfn>
<dt><dfn lt=svb>svb unit</dfn>
<dt><dfn lt=dvb>dvb unit</dfn>
<dd>
Equal to 1% of the size of the initial containing block
[=large viewport size=],
[=small viewport size=],
and [=dynamic viewport size=]
(respectively)
in the direction of the root element's block axis.
<dt><dfn id="vmin" lt="vmin">vmin unit</dfn>

<dt><dfn lt="vmin">vmin unit</dfn>
<dt><dfn lt="svmin">svmin unit</dfn>
<dt><dfn lt="dvmin">dvmin unit</dfn>
<dd>
Equal to the smaller of ''vw'' or ''vh''.
Equal to the smaller of ''*vw'' or ''*vh''.

<dt><dfn id="vmax" lt="vmax">vmax unit</dfn>
<dt><dfn lt="vmax">vmax unit</dfn>
<dt><dfn lt="svmax">svmax unit</dfn>
<dt><dfn lt="dvmax">dvmax unit</dfn>
<dd>
Equal to the larger of ''vw'' or ''vh''.
Equal to the larger of ''*vw'' or ''*vh''.
</dl>

<wpt>
Expand All @@ -1805,6 +1960,18 @@ Viewport-percentage Lengths: the ''vw'', ''vh'', ''vi'', ''vb'', ''vmin'', ''vma
css/css-values/viewport-units-css2-001.html
</wpt>

ISSUE: Originally the (unprefixed) viewport units were defined
relative to the viewport size in general.
The dynamism of browser chrome shifting in and out during scrolling was invented later,
and following Safari's lead, most UAs mapped these units to the larger size.
Defining it this way is prettier in many cases,
but can also block critical content (such as toolbars, headers, and footers) in others.
It's therefore not entirely clear whether this is the best mapping.

ISSUE: Should we have dedicated ''lv*'' units for the [=large viewport size=]?
That would give authors an explicit version, and allow the unprefixed units
to maybe do smarter things to avoid obscuring critical content.

In situations where there is no root element
or it hasn't yet been styled
(such as when evaluating <a>media queries</a>),
Expand Down Expand Up @@ -4737,7 +4904,8 @@ Acknowledgments</h2>
of this module.

Secondly, we would like to acknowledge
Koji Ishii
Anthony Frehner,
Koji Ishii,
and
Xidorn Quan
for their comments and suggestions,
Expand Down

0 comments on commit 0f78ba4

Please sign in to comment.