Adding new relative units RCH and REX

chrislachance commented 3 years ago

Background

Currently today, there is support for relative root level 'em' width, aka. 'rem' (https://www.w3.org/TR/css3-values/#rem), but not root 'ch' nor root 'ex' (https://www.w3.org/TR/css3-values/#font-relative-lengths). I'd like to see that change.

Proposal

When considering WCAG 2.1 1.4.8 (https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-visual-presentation.html), its pretty clear that a value like 80rem won't guarantee a layout will meet this requirement. I believe that something like 80rch would be far more effective (or at least a lot closer to achieving this without JS).

As for 'rex' (which honestly would be really fun to use), some typography and visual designers suggest that vertical rhythm in a design should be driven by x-height (or 'ex'). (#22 - https://uxdesign.cc/the-ui-ux-tips-collection-volume-one-f69f0969ed17#ebf5). Using the baseline font (user preference or design choice), the design should vertically scale accordingly.

Using 'rem' / 'rch' for horizontal spacing & 'rex' for vertical seems to be more inline with the intent of spacing metrics, that are fluid based on the user's preference or style-set font family.

Advantages and Drawbacks

Advantage: Would round out the existing REM value for relative values
Advantage: UI is more flexible and consistent to user preference (if fonts aren't overwritten by a fixed style)
Advantage: RCH allows us to set a universally readable width at the root level, like some use REM for
Disadvantage: Cost of implementation for a potentially un-used unit
Disadvantage: Mixed support across various browsers for a bit

Current Workarounds

JS and CSS variables (custom properties) could do this today (https://codepen.io/chrislachance/pen/zYoJPvP?editors=1100). Does create layout instability if not properly dealt with.
Some fonts render 1ch or 1ex as .5em. This may work, but it would be sporadic, and miss the intent.
Could be faked by using .5rem, but still misses intent.
And for 'rch', JS could read & parse each line and see which characters overflow and adjust width dynamically.

P.S. This is my first time proposing. Thanks to Adam Argyle for pointing me in the right direction (especially to proposal with a nice template to follow!)

fantasai commented 3 years ago

I think rch and ric seem pretty reasonable to add. I'm a little skeptical about rex though. When setting line-height on the root you can just use ex. Beyond that you probably want to match the root's line rhythm, whatever it is.

fantasai commented 3 years ago

What's an example of a page in which rch is necessary and ch itself is insufficent?

chrislachance commented 3 years ago

Sure, I put together an example of what this might look like.

I'm also going to update the proposal, looks like the only way to do the workaround is using JS that creates custom properties, which unfortunately creates layout instability if not properly handled.

Demo https://codepen.io/chrislachance/pen/zYoJPvP?editors=1100

PS: How would you use the root's line-height however for setting padding, etc? As aside, seems strange to me that line-height uses EM instead of EX as well. Various fonts sit very differently within the space allotted for them, and EX targets the actual size of the font's x (hopefully), not the generic pixel bounding box set by font-size. (Think I've understood that logic properly.)

chrislachance commented 3 years ago

One more example of how REM fails to cap character count accurately when a font that is miniature is saying its 16px. https://codepen.io/chrislachance/pen/QWGVQme?editors=1100

fantasai commented 3 years ago

Agenda+ to discuss whether to add rch and ric.

@chrislachance Wrt the relationship of glyph size and line height, you might want to see the latest proposals in css-inline-3. https://www.w3.org/TR/css-inline-3/#line-height particularly text-edge and leading-trim.

chrislachance commented 3 years ago

Text-edge stuff & leading-trim look awesome. Very exciting.

As for RIC, don't think I'm familiar with that measurement, didn't see it in issue tracker. I assume you mean REX as proposed above?

Finally, thanks for the heads-up & for considering for review.

jfkthame commented 2 years ago

If we're going to do this addition (I don't personally have a clear idea of how useful it'll be, but also don't see any reason to oppose it), then I think we should consider simply having r versions of all the font-relative units in https://drafts.csswg.org/css-values-4/#font-relative-lengths. So that would mean adding rcap as well as rex, rch, and ric.

(No, I don't have a concrete use case for it. But it seems logical to do the full set, so that authors know that for any font-relative unit, they have both the "local" value and the root-element value available, rather than trying to pick and choose which of the units get a root-element version and which don't.)

litherum commented 2 years ago

This seems reasonable. Low implementation cost.

css-meeting-bot commented 2 years ago

The CSS Working Group just discussed rch and rex, and agreed to the following:

RESOLVED: Add root-relative variants of *all* the font-relative units, named r*

The full IRC log of that discussion

<fantasai> Topic: rch and rex
<Rossen_> call dropped... not object but like to have the note added
<TabAtkins> ScribeNick: TabAtkins
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/6034#issuecomment-925972959
<TabAtkins> fantasai: request for rch, represeting the root ch size, and rex for root ex size
<TabAtkins> fantasai: I think adding rch totally makes sense, and adding ric as analog for ic
<TabAtkins> fantasai: don't quite see the use-case for rex, tho it's simple to implement
<gtalbot> hi florian :)
<TabAtkins> fantasai: So my suggestion is just ot add rch and ric for now
<TabAtkins> fantasai: And see if there's a need
<TabAtkins> fantasai: but jonathan kew suggested we just do the full set of font-relative units
<fantasai> TabAtkins: I agree with jfkthame, having half or more available and some not seems bad for authors
<fantasai> TabAtkins: if adding more than one, add all of them
<Rossen_> q+
<TabAtkins> fantasai: so proposed resolution is to add r* variants of all the font-relative units
<astearns> ack Rossen_
<TabAtkins> Rossen_: adding stuff is easy, removing is very difficult
<TabAtkins> Rossen_: I'm not hearing strong use-cases
<TabAtkins> Rossen_: We can always add later
<TabAtkins> Rossen_: Would be better to have a hygiene of use-cases we are solving as we expose more
<TabAtkins> Rossen_: Otherwise later we scratch our heads over something that's not quite baked
<TabAtkins> Rossen_: So unless we have strong use-cases, let's just add things the ones we know about now
<TabAtkins> astearns: So are you suggesting only adding rch?
<TabAtkins> Rossen_: ONly rch and rex, yes
<TabAtkins> astearns: I'm only seeing a use-case in the issue for rch
<TabAtkins> fantasai: and ric
<astearns> ack fantasai
<TabAtkins> fantasai: I don't particularly see a strong use-case for rex
<TabAtkins> q+
<TabAtkins> fantasai: But whether we add it now or later, we'll have to reserve that name, because we'll want all the units, if they ever get a root-relative variant, to follow the same pattern
<TabAtkins> fantasai: So in terms of what it allows for our APIs in the future, the name is reserved anyway; we're not limiting ourselves either wya
<astearns> ack TabAtkins
<fantasai> TabAtkins: Normally I'm 100% behind what Rossen just said, and expressed strongly for other proposals
<fantasai> TabAtkins: but the issue is that there is more than one competing concern here
<fantasai> TabAtkins: and author confusion over what's allowed or not is a significant issue here
<fantasai> TabAtkins: if only one rem, that's easy to remember. if all units, that's easy to remember
<fantasai> TabAtkins: if just some arbitrary subset is allowed, then that is confusing
<fantasai> TabAtkins: If there was a significant implementation complexity, or even a moderate one, then I'd be sympathetic
<Rossen_> q?
<fantasai> TabAtkins: but after adding one root font relative unit, adding more is very cheap
<fantasai> TabAtkins: so adding all of them is what makes the most sense for authors, from usability perspective
<smfr> agree with TabAtkins
<TabAtkins> Rossen_: That's a compelling point
<TabAtkins> Rossen_: I did factor what you said in, in the way it was originally proposed
<TabAtkins> Rossen_: So I'm less concerned now
<TabAtkins> astearns: So proposed reoslution is to add all the root-relative font-relative units?
<argyle> +1
<TabAtkins> astearns: Concerns? Objections?
<TabAtkins> RESOLVED: Add root-relative variants of *all* the font-relative units, named r*

fantasai commented 2 years ago

Edits checked in and republished on /TR.

w3c / csswg-drafts