diff --git a/css-values-4/Overview.bs b/css-values-4/Overview.bs index d1248e0d229..e0ea984cdad 100644 --- a/css-values-4/Overview.bs +++ b/css-values-4/Overview.bs @@ -544,11 +544,9 @@ CSS-wide keywords: ''initial'', ''inherit'' and ''unset'' All of these keywords are normatively defined in the Cascade module. [[!CSS3CASCADE]] - 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 @@ -1737,25 +1735,158 @@ Font-relative Lengths: the ''em'', ''ex'', ''cap'', ''ch'', ''ic'', ''rem'', ''l -->

-Viewport-percentage Lengths: the ''vw'', ''vh'', ''vi'', ''vb'', ''vmin'', ''vmax'' units

+Viewport-percentage Lengths: the ''*vw'', ''*vh'', ''*vi'', ''*vb'', ''*vmin'', ''*vmax'' units + + ISSUE: + This section is UNDER CONSTRUCTION. + Please use CSS Values and Units Level 3 + as an implementation reference for now. The viewport-percentage lengths are relative to the size of the initial containing block. 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. - Note that the initial containing block's size is affected by the presence of scrollbars on the viewport. - ISSUE(1766): Level 3 assumes scrollbars never exist because it was hard to implement. This is making authors unhappy. +
+The Large, Small, and Dynamic Viewport Sizes
+ + There are three variants of the [=viewport-percentage length=] units, + corresponding to three (possibly identical) notions of the viewport size. + +
+
large viewport +
+ The large viewport-percentage units + are defined with respect to the large viewport size: + 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. + +
+ 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. +
+ +
small viewport +
+ The small viewport-percentage units + are defined with respect to the small viewport size: + 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. + +
+ 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. +
+ +
dynamic viewport +
+ The dynamic viewport-percentage units + are defined with respect to the dynamic viewport size: + 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=] + are not stable + 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.) +
+ + 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 must 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. + Note however that the [=initial containing block=]'s size + is affected by the presence of scrollbars on the viewport. + + ISSUE: Level 3 assumes scrollbars never exist because it was hard to implement + and only Firefox bothered to do so. + This is making authors unhappy. + Can we improve here? + +
+The Various Viewport-relative Units
+ + The [=viewport-percentage length=] units are:
-
vw unit +
vw unit +
svw unit +
dvw unit
- 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.
In the example below, if the width of the viewport is 200mm, @@ -1765,25 +1896,49 @@ Viewport-percentage Lengths: the ''vw'', ''vh'', ''vi'', ''vb'', ''vmin'', ''vma 
h1 { font-size: 8vw }
-
vh unit +
vh unit +
svh unit +
dvh unit
- 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. +
vi unit +
svi unit +
dvi unit
- 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.
vb unit +
svb unit +
dvb unit
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. -
vmin unit + +
vmin unit +
svmin unit +
dvmin unit
- Equal to the smaller of ''vw'' or ''vh''. + Equal to the smaller of ''*vw'' or ''*vh''. -
vmax unit +
vmax unit +
svmax unit +
dvmax unit
- Equal to the larger of ''vw'' or ''vh''. + Equal to the larger of ''*vw'' or ''*vh''.
@@ -1805,6 +1960,18 @@ Viewport-percentage Lengths: the ''vw'', ''vh'', ''vi'', ''vb'', ''vmin'', ''vma css/css-values/viewport-units-css2-001.html + 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 media queries), @@ -4737,7 +4904,8 @@ Acknowledgments of this module. Secondly, we would like to acknowledge - Koji Ishii + Anthony Frehner, + Koji Ishii, and Xidorn Quan for their comments and suggestions,