User Interface Typography
imperavi.com
imperavi.com
That said, I'm enjoying the rapid journey through typography.
https://fonts.google.com/knowledge/glossary/serif
https://fonts.google.com/knowledge/glossary/sans_serif
https://fonts.google.com/knowledge/glossary/slab_serif_egypt...
Google Fonts also has helpful articles like, "Making sense of typographic classifications": https://fonts.google.com/knowledge/introducing_type/making_s...
em "relative sizing" is still "relative to some pixel value". The default is 16px so 1.1em is just the same as 17.6px.
"cm" is also defined to be a certain number of px.
The website has no idea if you're using a high DPI monitor or just zoomed out to 25%. To say "always appear as exactly 1cm to the user" would obviously not be desired as you would lose the ability to zoom.
The default is absolutely not 16px. 16px is a common default value but different browsers and devices will have different defaults and most browsers will let the user customize their font size. By assuming that 1em == 16px you are ignoring the user's preference and likely making the text hard for them to read.
https://nicolas-hoizey.com/articles/2016/03/02/people-don-t-...
1rem == the font size of :root and 1em == the font size of the current element. It is true that these have some equivalent in pixels and 1rem very often is 16px. But that isn't guaranteed and shouldn't be assumed. You should respect the user's preferred font size.
This is impossible because what's desired depends on the font. Of course I can foresee the "we should respect the user's preferred font" response, but that's also impossible because you don't know the font metrics of that are and then it turns out that stuff breaks because the font is tons wider or whatnot. This is also the problem with "respecting the font size". Never mind the aesthetical reasons for choosing a different font of course.
This is why browsers have zoom, which solves the problem without tons of downsides. It's not always perfect, but much more manageable for everyone. Firefox can set a default zoom level too, and it remembers the zoom level per-site.
For all practical purposes the default is 16px. All browsers ship with that as a default, and those that don't should be doing that. This entire feature is fundamentally broken and a holdover from the past.
>This is impossible because what's desired depends on the font.
I'm confused by this statement. Let's say I'm using a font that looks smaller than average. To compensate for that I (the developer/designer) set the font-size of my body text to 20px instead of 16px. Using rem, it'll be 1.25rem.
Now when someone with bad eyesight comes on my website and they have their default font-size set to 18px instead of 16px, the body text is 18*1.25=22.5
They will still see a larger text (22.5px) than the average person (20px), regardless of the font I picked.
If I had set the font-size in px, everyone would get the same size regardless of their preference.
> you don't know the font metrics of that are and then it turns out that stuff breaks because the font is tons wider or whatnot
Your site breaks so you make the text too small for the user to read? Browsers also have accessibility options to override website's custom fonts. So your site is broken either way, best to fix it an let the user have their preferred experience than mitigate it for some users and leave other users broken.
> This is why browsers have zoom, which solves the problem without tons of downsides
Zoom is great as well. But what downsides does it avoid? If the user wants their text wider your layout that assumes a max width for text is still going to break. The main downside that it avoids is web developers assuming that 12px text is easy to read.
I could argue that zoom is a hack to mitigate websites that use px for things that need to be readable. It scales px, which fixes a problem that wouldn't exist in the first place if the developer just used em.
> All browsers
Not all browsers. But most common browsers.
But I think at the end is what is the point of all of this? You are dismissing an approach with clear upsides without arguing what advantages the px approach brings. Sure, maybe most browsers are 1rem == 16px and maybe zoom is a good enough mitigation. But what advantage do you get by relying on this? I think you are right that browsers have done lots of good work to mitigate sites that set the body text to 12px, but it still seems that doing that doesn't have any advantages over just using em.
Doing something like this is the only way a single website can work across a wide range of screen sizes, DPIs, zoom levels, and things like that.
If what you printed wasn’t accurate, something else was at play.
If you created a document using an A4 template and measured objects within this document using millimetres, when printed the objects would not be printed at exactly that size.
I know this because I've tried to do exactly that, and tried various permutations - on my specific printer I found that the warping was sometimes non-linear along the vertical axis! Maybe I've just got a particularly crap printer... Oh, Brother!
Let's say you have a fixed list of font sizes (and you probably want to), that goes like this: 0.75em, 0.875em, 1em, 1.25em, and 1.5em. It's all good if you have an element with `font-size: 1.25em`, because that's on the scale. But if a nested element has 0.875em, it'll actually be 1.25*0.875 = 1.09375em, because it'll be relative to the parent font size.
So if you don't want your UI to have 17 different font sizes with fractional pixels, "absolute" units like px or rem are preferable. They still don't map 1:1 to screen pixels, so it shouldn't be a problem for high DPI displays.
https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_...
I believe, Browsers these days, are smart enough to let you zoom your interface up/down.
I’ve glanced at a few sections of it too, and although there’s definitely some solid stuff in this, there’s also some straw-manning, implausible assignation of virtue, and unwise recommendation.
Some examples from a handful of pages I went through.
• Grouping: under the Rectangle heading, the problem is not at all that there are two rectangles, it’s just a severely unbalanced second paragraph.
• Anchor points: ugh, mostly nasty examples that show why this is something easy to do that produces tolerable results, but it’s normally a long way off the best that you could produce if you just ignored the “rule”. But instead of trying to teach to produce excellent results, you can legitimately try to teach not to produce bad results. Maybe that’s the goal instead? Anchoring is perhaps a little more dependable than freeforming it if you don’t know what you’re doing. But it’s no panacea or even always usable.
• Lines of force: look, most of those examples only need them to claw back some semblance of reason since they made a chaotic layout. And as for that numbered thing… I don’t find it “compelling” and would like it to remain “unusual”.
• Rhythm and variety: what’s suggested at the start is very risky. Monotonous is reliable. Monotonous works. Users understand monotonous. I also want to draw attention to some broken rhythm and painful variety on the page itself: from the paragraph beginning “Generally” to the paragraph beginning “Just” is a mess, with inconsistent spacing and unclear grouping. It’s bad on small and large viewports, in two different ways. Some background shading on the figures would help a lot (one of many possible solutions).
• Modular scales (sizing text based on geometric sequences): oh no. This is just plain bunk, genuinely having no redeeming features and just being arbitrary mediocrity at best. I expanded on this at length six months ago in https://news.ycombinator.com/item?id=36000879 and the following comments. I will also rail against this page’s suggested applications of sizes: do not go below 16px as much as it suggests doing, and never go below 12px. Buttons? 16px. Form labels? 16px. Small text? Avoid it, but I will begrudgingly allow 14px in very specific, very restricted situations. Tags, labels, badges, statuses? C’mon, 14px is probably just fine for you.
• Vertical rhythm: I was going to say “oh no” again, because for general web content rhythm is not only roughly impossible to get strictly correct and has no demonstrated value, but even though that’s what the term means, that’s not what the article is about. It shows a dodgy example of an overcomplicated baseline grid, then goes to talking about sizing gaps as multiples of some scale, and thinking a little about hierarchy in the values you choose. So instead I’ll say “oh no” about misuse of a well-known term.
I’ve spent long enough on it for now. I really should get round to finishing off a new section for my website where I go through these sorts of reviews in more detail, rather than tending to publish them just on HN.
—⁂—
Let me add one useful user interface design guideline: the document title should have the most specific piece at the start, not the end. This site currently has its endianness the wrong way round.
BAD: UI Typography | Principles | Responsive typography
GOOD: Responsive typography | Principles | UI Typography
I'll just address your strongest point about modular scales. Its redeeming quality is that it provides a predictable scale and aligns everyone on the team about text sizes. There is some dubious benefit about "harmony", and in the final paragraph the author acknowledges that this system can be ignored. There's no need to be so adamantly opposed to it, though.
The fixed font size and increased line height are uncomfortable and unnecessary: as a user, I have preferred ones set already. There seems to be such a trend among typographers (and maybe web designers), as noted multiple times at [1].
Then it places light gray text on dark gray background, but near pure white pictures, which make that text uncomfortable to read. With some odd bright icons preceding the image captions. Possibly it looks different with a light system theme (inherited by a web browser, handled by CSS media queries).
The thumbs-down icon near "Hard to read" text was hard to read, being pink on dark background.
As mentioned by others, a table of contents is missing for such a sequence of web pages.
As for the written advises, some of them sound sensible, but:
> It is preferable to use serif fonts in interfaces where there will be a lot of text information, such as articles, news, and long reads.
I find serif fonts very uncomfortable to read, especially for longer texts, such as books. Have read elsewhere (though probably also without much of a justification, but at least matching my own observations) that fonts without serifs are generally more comfortable to read, especially from a screen. Actually even this "book" appears to use a sans serif font, Inter (though I have custom font loading disabled, so seeing a sans serif font either way).
Then it proceeds to describe many other ways in which one can mess up fonts for users (choosing different sets of fonts, pairing them, tweaking their properties), but as an instruction, not a warning.
I would replace all that with the "do not mess with others' fonts" advice, and perhaps a similar one for colors.
Failure.
It really doesn't help on desktop that that wraps the table into columns. It is unlabelled and didn't "look" like a ToC
And "to learn it to a certain degree" is fundamentally different from "cannot be learned".
Nobody expects to become a world famous typographist by simply following a tutorial. What they can do, is acquiring an applicable skill for their occupation.
And of course violin can be learned to a enjoyable degree by most people if they wish to do so. You'd need fair bit of talent to make a career in the classical world, sure. But to play it enjoyably is something an amateur can certainly achieve. (Speaking as a talentless amateur violinist)