Complete Support for Font relative length units: rem, em, ex, ch, cap, ic + more

With 0.2.0 alpha of the polyfill now supporting the poster childs rem and em for responsive designs, it would be nice to have complete support for font size relative length units to complete the picture.

With the ability to use the element related em unit for container widths, adding other font size relative units should be just a matter of “while-listing” and performing the same logic as for rem (root element font-size) or em (selected element font-size) respectively.

These are also long supported by browsers. For the selected element (like em):

• ex: Equal to the used x-height
• ch: Equal to the used advance measure of the “0” (ZERO, U+0030) glyph (Latin fonts), see ic below
• cap: Equal to the used cap-height (capital Latin letter)

Browser support for additional font size relative sizes of CSS Values 4 is unknown / unavailable on caniuse or MDN, but could be added preemptively to be available when support is eventually implemented. Rules are virtually the same.

Selected element font:

• ic: Equal to the used advance measure of the CJK water ideograph (CJK fonts), see ch above

Root element font:

• rex
• rch
• rcap
• ric

https://drafts.csswg.org/css-values-4/#font-relative-lengths https://drafts.csswg.org/css-values/#relative-lengths https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Values_and_Units#dimensions https://developer.mozilla.org/en-US/docs/Web/CSS/length

Thank you!

---

Some may argue that Point pt and Pica pc are also “font related”. While certainly standard in print and PostScript, both are actually absolute units based on the inch. Given their straight forward computation into pixels, both could be easy to implement, despite being highly inaccurate for modern screen resolutions. However, designers coming from print might find them useful.

• pt: 1/72nd of 1in.
• pc: 1/6th of 1in == 12pt.

[argyleink]

From what I’ve learned while waiting for the lh unit and other font relative features, is that the font information isn’t always even available for the browser engine, let alone JS. Fonts themselves can have bad information in them that’s been accounted for by a browser, like impossible stuff for a polyfill author to know about font measurements. I agree attempts would work in many cases but not all (hence the brittle comment) because all JS can do is synthetically attempt a recreation of the environment needed to make a measurement, and while it’ll be fine for many fonts, it wont be perfect for all of them.

But, to devils advocate my own comment, that’s all a polyfill can do, is synthetically attempt as best it can, so maybe that’s not a good enough reason to reject the feature. Definitely up to the authors of the plugin here, to let them assess their own amount of fidelity and complexity they want to balance and manage over time with this polyfill.

So I see both sides here! Sorry if that’s not helpful lol. But it’s a fair request to want to use relative fonts in a container query, the spec allows it and the final implementations will too, but it’s also on a fine line cusp for maintenance and management from a maintainer POV, and few folks may actually leverage this feature. ⚖️

hope this was helpful 🙂

[WebMechanic]

I believe @argyleink may have valuable insight working on VisBug and he knows a thing or two about CSS