4 ms·

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

by mrec 6y ago

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. https://manishearth.github.io/blog/2017/08/10/font-size-an-unexpectedly-complex-css-property/ https://manishearth.github.io/blog/2017/08/10/font-size-an-u...

brundolf 6y ago
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.
- jefftk 6y ago
  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.
  - brundolf 6y ago
    When it gets to the point of diving into the last two, the article literally says: > Alright, this is where it gets complicated. I haven't implemented any of the above myself, but the author at least seems to think the last two are where the complexity is concentrated.
    - jefftk 6y ago
      Sorry, you're right. I've gone back and read the article and there was complexity in those two that I had completely forgotten about.
- kelnos 6y ago
  > 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.
- rikroots 6y ago
  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!

by mrec 6y ago

brundolf 6y ago

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.

jefftk 6y ago
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.
- brundolf 6y ago
  When it gets to the point of diving into the last two, the article literally says: > Alright, this is where it gets complicated. I haven't implemented any of the above myself, but the author at least seems to think the last two are where the complexity is concentrated.
  - jefftk 6y ago
    Sorry, you're right. I've gone back and read the article and there was complexity in those two that I had completely forgotten about.
kelnos 6y ago
> 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.
rikroots 6y ago
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!