Readability improvements for relative length units? #17609
Labels
Content:CSS
Cascading Style Sheets docs
effort: medium
This task is a medium effort.
help wanted
If you know something about this topic, we would love your help!
MDN URL
https://developer.mozilla.org/en-US/docs/Web/CSS/length
What specific section or headline is this issue about?
Relative length units based on viewport
What information was incorrect, unhelpful, or incomplete?
Background:
According to the supporting links, there's been a long-standing issue in mobile Safari (and Chrome) where
100vh
doesn't behave as expected when the browser chrome expands and retracts. It looks like this was recently resolved by the addition ofsvh
,lvh
anddvh
length units to the CSS spec in July 2021, and that Safari shipped support for these newer units in v15.4, with thevh
unit retaining its original ambiguous behavior.Discussion:
There's clearly a lot of history here, but I feel like the motivation for the newer units gets a bit buried in this article's text. The viewport resizing behavior is described in a detailed and accurate way, but a simple disclaimer on the default
vh
unit may more effectively catch a reader's attention.The concern is that a newer developer may scan this article or follow a link directly to the
vh
definition, note that prefixed*vh
variants exist, but still opt for the defaultvh
as the most 'basic' choice after seeing that it has full support in the browser compatibility table. This also seems likely if they're using a mobile emulator that won't exhibit the dynamic browser chrome resizing of an actual mobile device, in which case there would be no observable difference between the new prefixed variants and the original unit.The semantics of 'default' feels a bit inverted here -- often a default value will be a safe choice that serves the needs of most users. This seems to not be the case this time, as the newer units were created to solve issues caused by the original.
What did you expect to see?
I think this section is already good, but could be made even better with a more prominent indication that the default
vh
unit may be problematic for full-page displays.Some ideas:
I'm wondering if the browser compatibility data for
vh
would benefit from adding an implementation note to those mobile browsers which interpret100vh
as100lvh
.vh
is a safe choice across modern browsers, which is perhaps a bit misleading. An asterisk on affected mobile browsers could help developers self-identify the extent to which dynamic viewport sizing impacts their use case, since not all browsers feature dynamic chrome.If this sort of information doesn't belong in the browser table, perhaps a callout under the 'Default' section would be helpful.
Note: For example, a browser might implement the default viewport-percentage unit for height (vh) that is equivalent to the large viewport-percentage height unit (lvh). If so, this could obscure content on a full-page display while the browser interface is expanded.
Something else?
No action, it's already clear enough
Do you have any supporting links, references, or citations?
Webkit bug report
Chrome blog
w3c/csswg-drafts#4329
Do you have anything more you want to share?
No response
MDN metadata
Page report details
en-us/web/css/length
The text was updated successfully, but these errors were encountered: