My favourite example of the thousand-yard-stare horror of web specs is Manish's "Font-size: An Unexpectedly Complex CSS Property". It's awful and hilarious and just keeps getting worse and worse and worse.
Yeah so this is exactly the kind of thing I'm talking about:
-----------------
The syntax of the property is pretty straightforward. You can specify it as:
- A length (12px, 15pt, 13em, 4in, 8rem)
- A percentage (50%)
- A compound of the above, via a calc (calc(12px + 4em + 20%))
- An absolute keyword (medium, small, large, x-large, etc)
- A relative keyword (larger, smaller)
The first three are common amongst quite a few length-related properties. Nothing abnormal in the syntax.
The next two are interesting.
-----------------
I've been doing front-end web dev for nearly ten years, and I've never even heard of those last two, much less used them. That's the kind of thing a new browser could defer support for until after the MVP, while barely detracting from the average user's experience.
Though this does remind me that i18n is a thing, and how gnarly of a problem it must be for a piece of software so concerned with text flow/layout, and ideally it's not something that a theoretical upstart browser would punt on.
If people feel the need to use text inside their <canvas> elements, I've done some (not very rigorous) research on how JS engines interpret font size instructions in their canvasRenderingContext2d environments:
- Absolute size keywords ('xx-small', 'x-small', 'small', 'medium', 'large', 'x-large', 'xx-large', 'xxx-large') may-or-may-not work — and the resulting size may-or-may-not have a relationship to the <canvas> elements surrounding environment.
- Relative size keywords ('larger', 'smaller') can be hit-and-miss too.
- Absolute length values, defined with px, pt, in, cm, mm, pc, will usually work as expected.
- Viewport lengths (vw, vh, vmax, vmin) will often work; note that these lengths are set on creation and don't automatically resize when the viewport dimensions change.
- For lengths defined by the font itself, rem will use the root element's font size for its reference; %, em, ch can be less helpful. Again these won't automatically resize in a responsive environment.
- Of the rest, Q is not supported by Safari browsers, while cap, ic, lh, rlh, vb, vi are not supported by any browser. Avoid!
> I've been doing front-end web dev for nearly ten years, and I've never even heard of those last two, much less used them.
Huh, that's interesting to hear you say that. I hardly do any web development at all, but I was using both of those things for personal/toy web sites over a decade ago.
Just goes to show you that even rank amateurs can end up exposed to things that professionals haven't seen, for whatever reason.
While I think you're right that the last two are very uncommon, they are not a large contributor to the complexity of handling font sizing. Once you've done all the rest, I suspect you could add them with <5% more work.
Leaving out rare features to build a browser more quickly only makes sense if those features let you remove a lot of complexity from your implementation.
https://manishearth.github.io/blog/2017/08/10/font-size-an-u...