Every Layout (https://every-layout.dev/rudiments/axioms/) is a fantastic resource that really opened my eyes to a fundamental problem at the heart of most design systems and component libraries: they don't compose well or scale cleanly, because they're not built on the right primitives nor based on first principles. Whereas Every Layout demonstrates that it's possible to embrace "axiomatic design", including use of a typographic scale as the basis for robust, accessible, composable, layouts and designs. Highest recommendation.
It's easy to get sucked into composing interfaces with component libraries and forget some of the many nuggets in this guide. Like I'm not sure what possesses me to use gray fonts but I completely agree they're harder to use and there are better ways of communicating disabled or visited states. I'm definitely going to be taking a closer look and evaluating my product with some of these recommendations.
This book recommends font sizes in `px`. Why are people still doing that? Me and my high DPI monitor hate you. Use relative sizing in `em`, or even just actual `cm`.
Browsers don't treat "px" as actual pixels the monitor renders.
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.
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.
> 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.
>> You should respect the user's preferred font size.
>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.
I think you have some good points, but others just don't make sense.
> 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.
No; it never really meant "exactly one screen pixel". Even the CSS1 specification from 1996 doesn't say that: "If the pixel density of the output device is very different from that of a typical computer display, the UA should rescale pixel values. The suggested reference pixel is the visual angle of one pixel on a device with a pixel density of 90dpi and a distance from the reader of an arm's length. For a nominal arm's length of 28 inches, the visual angle is about 0.0227 degrees."
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.
I think this entire thread demonstrates why designers should not even be specifying text size. We should make better use of user-defined preferences, and browsers should make setting them up more prominent. Designers sitting in offices 3000 miles away from me should not be deciding how my browser renders text for me to look at.
You can't make any design with purely "user defined preferences" because none of the metrics will be reliable and if the settings deviate too far from the average things get all wonky pretty quickly, even for fairly simple designs.
Having tried to print a physically-accurate scale on a non-commercial printer I would be surprised if a 1x1inch box actually measures the same in real life.
I’m confused and not sure what you mean. The device knows what size it’s printing at (e.g. A4 which is 210×297mm). One some devices with bad feeders you might get local error up towards 1% in the feed direction (probably <1‰ in the perpendicular), but on decent printers it’ll always be well below 1%.
If what you printed wasn’t accurate, something else was at play.
Yeah it knows it's printing A4, but it can't print edge-to-edge, if you print a black rectangle the white borders are not a uniform size.
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!
Being able to print edge-to-edge is not necessary, and is mostly to do with practical feeding limitations. Alignment on the sheet is also allowed to suffer. But of what it does print, I’ve printed and observed printed a number of precise things on several different printers (mostly lasers, but at least one inkjet and a phaser, way back) with no visible warping. ¯\_(ツ)_/¯
I've just finished reading Refactoring UI, and the author has a good point against `em`: nested uses lead to fragmented sizes.
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.
The "rem" unit fixes that: it's "relative em" and relative to the root rather than parent. It's supported everywhere (even IE) and for new projects you should probably always use "rem" and never "em".
That's weird, I confirmed it on https://drafts.csswg.org/css-values before posting that comment, but now I can't find it anymore. Thanks for the correction.
I think this is OK. Eventually, this has to have a content. For instance, I still tinker a bit here and there with designs (and the code) and I tend to set the :root as in pixel and then derive the r/em from there. That way, I know where the primary pivot point for me is to the size of the type.
I believe, Browsers these days, are smart enough to let you zoom your interface up/down.
I find myself confused about what this is actually about. User interfaces, or general web content? It seems to skip blithely from one to the other, when they often have quite different requirements.
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.
(You could also drop the middle hunk likely with no ill effects, and I’d suggest -, – or — instead of | as a divider these days. | fell out of fashion over a decade ago.)
You make some good points, but most of your objections are based on strong personal preferences, just as the author's recommendations were. This is fine, but it goes to show that visual design can't be boiled down to a set of strict rules that must never be broken. Instead, all recommendations should serve as guidelines, which can be ignored if needed. I appreciate your judgment as much as the author's, yet you make the mistake in thinking that yours is objectively better.
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.
I don’t object to using a defined scales. Please have one; please. But I object to modular scales for the reasons I mentioned in the linked thread: they’re presented as virtuous, but they actually produce arbitrary, bland, inferior results, mediocre at best. It’s like some of the “golden ratio” guff people go explaining things with: it sounds nice, but it’s just plain nonsense. Therefore I will viciously attack modular scales as a concept every time I come across them (unless otherwise occupied). Someone’s wrong on the internet, and they’re misleading others.
I would like to rant about yet another website (book, article) on typography or accessibility worsening the typography and accessibility with their tweaks, and advising the reader to do the same.
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.
For me, this "Book" (which is actually just a series of web pages) failed the usability test when I got stuck wondering "where is the table of contents?" (usually in a side bar). After clicking "read the book" expecting a book i.e. a pdf, or something I could buy, I eventually discovered that the ToC is only present on the front page, prior to clicking through to read. Furthermore, the ToC is completely unlabeled, and inside a box which makes it look like a footer. A simple H1 "Contents" would have been helpful.
Same! After failing to find the table of contents, I decided that that was an intentional downgrade of the online version of the book as compared to the paid-for print one.
Typography matching I think cannot be learned, same applies to choosing which color goes well with other colors. Either you have a knack for it or not. Nonetheless, I'll check this one out.
Really? I think you are mistaken. There are rules for the things you mentioned, so you learn the rules. Both through reading them and through experimenting, because there is also a subjective component. You'll discover you like certain fonts, color combinations more than others.
Nah, it's like learning the violin. You can learn it to a certain degree, but to play it like Menuhin, sorry, to play it like it's actually enjoyable you have to have innate skill.
I think it's safe to say that "to learn it to a certain degree" is exactly what people want out of books like this.
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)
