Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Readability improvements for relative length units? #17609

Closed
devbynicole opened this issue Jun 24, 2022 · 0 comments · Fixed by #20269
Closed

Readability improvements for relative length units? #17609

devbynicole opened this issue Jun 24, 2022 · 0 comments · Fixed by #20269
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!

Comments

@devbynicole
Copy link
Contributor

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 of svh, lvh and dvh length units to the CSS spec in July 2021, and that Safari shipped support for these newer units in v15.4, with the vh 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 default vh 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:

  1. I'm wondering if the browser compatibility data for vh would benefit from adding an implementation note to those mobile browsers which interpret 100vh as 100lvh.

    • 'Can I use' already does something similar in the 'Known Issues' tab on their entry for viewport units: https://caniuse.com/viewport-units
    • The current appearance of the compatibility table suggests that 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.
  2. If this sort of information doesn't belong in the browser table, perhaps a callout under the 'Default' section would be helpful.

    • An existing sentence could be converted to a highlighted note, and add a clear summary of impact: 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.
    • Highlighting this text would give concerns about cross-browser inconsistencies for the default unit equal visual weight on the page with concerns about performance in the 'Dynamic' section just above. Right now the 'Default' text gets overshadowed by the notes in the sections above and below.
  3. Something else?

  4. 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
@github-actions github-actions bot added Content:CSS Cascading Style Sheets docs needs triage Triage needed by staff and/or partners. Automatically applied when an issue is opened. labels Jun 24, 2022
@sideshowbarker sideshowbarker added help wanted If you know something about this topic, we would love your help! effort: medium This task is a medium effort. and removed needs triage Triage needed by staff and/or partners. Automatically applied when an issue is opened. labels Jun 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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!
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants