| 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. |
- 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!