-
Notifications
You must be signed in to change notification settings - Fork 658
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
Adding new relative units RCH and REX #6034
Comments
I think |
What's an example of a page in which |
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 PS: How would you use the root's line-height however for setting padding, etc? |
One more example of how REM fails to cap character count accurately when a font that is miniature is saying its 16px. |
Agenda+ to discuss whether to add @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. |
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. |
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 (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.) |
This seems reasonable. Low implementation cost. |
The CSS Working Group just discussed
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//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* |
Edits checked in and republished on /TR. |
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
Current Workarounds
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!)
The text was updated successfully, but these errors were encountered: