back
73 comments
Looking at those typographic scales in context of modern computers always makes me wonder, why everyone adhere to original "letterpress" constraints?

Nothing against proven crafts when they serve well, yet all "typographic scales in CSS" I've seen so far always operated almost exclusively on font-size / line-height and seldom letter-spacing, almost never font-weight and never used other visual clues for expressing hierarchy and rhythm like decorative ornaments, different shades or even palette or some other creative tricks. Those are techniques that are sometimes used in the wild, built organically, but I have never seen them analysed in isolation, some colour theory telling that "you either bump-up font size by this factor or increase contrast between background and text to get such and such level of urgency".

What I find most strange is that, seemingly, everyone is fine with conveying the same information using two and more ways in parallel: size, visual contrast and disruptions in vertical rhythm. Making part of text bigger makes it stand out on it's own, since it disrupts vertical rhythm around it and also shines with thicker strokes. Side-effect of this is more visual contrast, something I'd call "pressure".

It is mostly the absence of content what constitutes the hierarchy -- the space around headings, indentation etc -- not the local "pressure" of the letters in headings. From my subjective perspective large contrasting text very often "screams" in my head.

Some time ago I've tried if would be possible to normalize that optical pressure across sizes (without changing weight); this was the result: https://codepen.io/myf/pen/oNLKzNY

In short, I think we should try to "tone down" blocks with large text when we have the opportunity, like:

(edit HN discards block element characters; think large square in "lighter" shade followed by two "heavier" lines of the same width below)

rather than keeping it same, like:

(think large square followed by two lines below, all of same shade, so the compact area of the square stands out even more.)

This is something that I’d say should mostly be handled in the font, and nowhere else. Variable fonts have the optical size (opsz) axis, which you can use to tweak things like glyph thickness and tracking based on the font size. It’s like full hinting used to be, but even better. I’d like to see operating systems move to defaulting to fonts that work this way.

I find your example interesting, but I hate things overriding letter-spacing like that, because it generally looks bad, and definitely looks bad in my chosen fonts. Need to finish off my article railing against people changing letter-spacing on body text, which is ridiculously common and always a bad idea. Line-height you take a bit too far, but the general concept of “larger text means smaller line-height” is one I wish more people understood. I’ve become partial to `* { line-height: calc(1em + 0.5rem) }` in the last year, which I find to work quite nicely as a single definition. For colour, it’s an interesting thing to consider, but I think it’s mostly the wrong solution—optical size s the proper solution for most of it, and my experience is actually that larger text normally wants to have a stronger colour rather than a weaker, because it’s a heading. But the interactions between font sizes and contrast in various guises is absolutely relevant, and I’m glad that the successor to WCAG’s terrible colour contrast technique, APCA (Advanced Perceptual Contrast Algorithm), takes font size into account in considering what makes for acceptable contrast.

!! Thank you for mentioning... and to add, human perception of contrast is actually driven more by the spatial characteristics (size, weight, thickness) than by the distance between two colors. This is a key reason that contrast measures that consider only the distance between two colors fail at predicting contrast.
The major problem with these kinds of tool is that they don’t explain why there is any virtue in the scales produced. My answer to that: there is none. Ever. In fact, I would go so far as to say that consistent geometric or modular scales like these are normally bad (though I won’t say always), and this kind of consistency actively undesirable, because our eyes and minds just don’t work that way, but value asymmetry and obvious differences in parsing and gathering information. You either end up with insufficient distinction, or grossly excessive variation.

That’s why you might do things like this (which I provide as an example of something reasonable, not as the only way of doing things):

1. Page title: positively huge (e.g. 4rem/64px/48pt). Probably not bold (though I freely invite you to use inline styles inside the title, something nowhere near enough people do).

2. Heading: quite large, and with a large gap before it (e.g. 2.5rem/40px/30pt, plus margin-top of 1.5em/60px and margin-bottom of 1rem/16px). Maybe bold, maybe not.

3. Subheading: somewhere between heading and body text in size, and perhaps with a decent-sized gap before it when not preceeded by a heading (e.g. 1.5rem/24px/18pt, margin-top 1.33em/30px and margin-bottom of 1rem/16px). Probably bold.

4. Subsubheading (rare) and certain sorts of captions (e.g. on figures and asides): normal size and distinguished by style instead. (e.g. 1rem/16px/12pt, but bold, and perhaps with a larger gap above.)

One thing covered incidentally in this sample scheme is the use of asymmetric margins to visually separate sections. That’s normally a good idea, but for some reason people don’t often try to fit it into their neat mathematical constructions—though you will note this tool’s sample area using such asymmetry unremarked. Probably because their formulæ are arbitrary anyway.

Another thing to note is that for general typography you don’t need many levels. As far as major sizes and styles are concerned, I’m sceptical of any general-use model that goes beyond five (title, heading, subheading, caption, body text). As far as headings are concerned, if you’re using more than title + two more, you should probably reconsider your content structure.

Cast off the tyranny of typographical scales. They have the appearance of wisdom in promoting rigour, but they are of no value.

> You either end up with insufficient distinction, or grossly excessive variation.

That’s the point of scales — to provide structure to any scale of values so there’s distinction without excessive variation.

I’m saying that geometrical scales are precisely what end up with at least one of those two problems. If the ratio at each level is too small, then the first few up from your base text size are too close to body text to be usable, and so people go skipping levels, even though that obviously corrupts the mathematical purity of the concept. If the ratio at each level is enough to make them useful, then you get too big (and too small) too quickly.

The only reason their values might seem to make any sense is if you have this weird idea that you should support at least five or six levels of headings. You actively shouldn’t.

Take the scale of 1.250 (the default of this tool). −1 is riskily small for any purpose, and −2 should never be used. +1 isn’t big enough for any kind of heading. +2 to +4 are reasonable heading sizes, but aren’t different enough from each other. +5 might be OK as a title, but very often you’ll want to go bigger. Depending on content, it might do for a heading style too.

Another mildly popular value: φ, 1.618. −1 is already too small for any purpose. +1 is decent for a subheading level, and +2 for a heading, and +3 for a title. (+3 is normally too big for any sort of heading; +4 could also be reasonable for a title.) But at that point you have only about four usable values, and where was the virtue in using a scale for them? You could have chosen more suitable values manually.

I’d like to recommend https://utopia.fyi/

A fluid typographic scale and spacing. Eliminates the need for breakpoints for text. I’ve used it on a number of projects with great success and love its simplicity.

Thank you for sharing this. You just removed an item from my to do list because I wanted to code something similar for myself and now I no longer need to since I can use this tool.
Thanks for this, reading it now
I believe they have a video on the site where they explain the reasoning and use.

This approach allowed me to remove all font size-related breakpoints from all my projects while achieving better visual results. Very grateful to its creators.

I can see this being useful for creating pleasing ratios between font sizes. Though I feel this may be less useful today than in the past. Headers, navs, and other elements often require responsive font sizes to adapt well to all screen sizes. You could still maintain a ratio if using a container query of the full document, but it's usually not a good idea to scale the body font more than a couple points up or down for readability.

I think this tool may be good for documents with careful typesetting and layout, but maybe not modern, interactive, responsive pages.

I disagree, changing the text size to adapt it to your eyes is a feature in every browser.
If you're talking about the browser zoom feature, then I don't believe any website should require you to use that to make the contents legible.

If that's not what you're saying, then you'll need to clarify.

The variation in display devices, environmental conditions, and quality of eyesight are large enough that that’s virtually impossible.
This is a nice visualization tool for seeing how these fonts will scale in your browser. Nice job!

I always consider: That 9px text might look readable on your 4K iMac, but how about your users on a budget Chromebook with a 720p display? And text rendering differences between browsers and operating systems is still something that severely affects how the text looks, especially at thin font weights that seemed to be all the rage a few years ago.

Also, for users that have any of the CJK languages as their default browser language, Chrome enforces a minimum font size of 10 (or 12?) pixel, so anything smaller should be avoided anyway if you care about rendering similarly for all viewers. https://bugs.chromium.org/p/chromium/issues/detail?id=36429
The fact you can even read a not-really-"9px" font on a retina display highlights how wrong browsers get things when they try to move too fast to quickly patch things. and more importantly, when the companies selling the new displays get a say on the html/css spec.

yeah, chrome and safari supported retina displays on day one, but at yet another huge consistency nuclear bomb that we now have to remember forever.

I have no idea what you’re trying to say, but I’m pretty sure you’re misunderstanding something.
Is the current bleeding edge CSS techniques to base everything off a base "px" value?!

I would imagine things would have progressed to have decent points or some other measurement based on screen actual size by now.

The current best practice is to use "em" measurements, where 1em is the size of the base font and zoom you've selected in your browser. Other measurements are scaled from there, so 2em is twice that size and .5em is half, etc.

In reality, the browser will use a variable number of pixels (and even device subpixels) to actually render the font or div -- but if you use all "em" measurements, all those sizes will have the same relationship to each other on the final device.

The 16px in the demo comes from the default base font size in the browser, which has 1em = 16px.

You just expanded on my poorly worded question :)

so, yes, it is still all based on a "base pixel value, that is not really a pixel".

Well, CSS pixels are not literal device pixels, they are kind of like the Android "device independent pixel" measurement.

The exact definition evades me since it's been a couple years I did any web development, but your px-based sizes won't look tiny on high-DPI screens.

72/inch iirc.
I'm currently using the 'minor third' scale on my site muxup.com (mainly because I didn't know what scaling to use and I saw it in use somewhere else). It seems fine, but I've found the headings aren't visually distinct enough if they're not right next to each other (i.e. it's hard to visually distinguish a h2 at 2.488 rem vs an h3 at 2.074rem). Perhaps I've chosen a bad scale, or perhaps I should be adding other visual markers to help distinguish the heading level?
Some good advice: https://practicaltypography.com/headings.html#:~:text=Certai...
> It’s fine to make the point size bigger, but just a little. Use the smallest increment necessary to make a visible difference. If your text is set in 12 point, you needn’t go up to 14 or 15 point. Try a smaller increase—to 12.5 or 13 point.

This is great advice. This is exactly what i think so many web design failed to follow, e.g. bootstrap.

I see a lot of cool sites in your HN profile! Which one are you talking about?
Edited to explicitly mention muxup.com - you won't see any current articles using nested headings (i.e. h3 in addition to h1 for the article title and h2 for article headings) as every time I've used one I've not liked how hard it is to differentiate, and haven't invested the time in revisiting the CSS to fix it.
This honestly outputs trash CSS. The scaling is abysmal. If I see a font size with a decimal in it, I’m going to assume you were about as lazy as this tool.
What's wrong with decimals in font sizes?
Any CSS for type that's not using clamp() for fluid scaling seems like a waste of time. Demo looks nice on desktop though.
clamp() is not supported by browsers merely three years old.
Nobody care about people with old desktop. Update your shit!
I hadn’t seen musical intervals used to express ratios between things that weren’t pitches, but I think it’s an interesting idea. I guess all they really are is a nice name for specific ratios, so it makes sense that they could be useful in more contexts. Has anyone seen them used in other interesting contexts?
If you block third-party fonts or Google Fonts specifically—and you should for privacy—this whole tool doesn’t work. Prefer first-party hosting, and always provide a native fallback (at minimum sans-serif, serif, monospace, or fantasy).
Or...you could work with a designer whose training and experience it is to make things like this look nice and work well. Instead of trying to have an formula or algorithm for everything, just because that's what you know.
Strange take, as if this isn't largely a tool for designers to experiment with type scales?
I'd be happy to be wrong, but this sure feels like another instance of a numbers/formulas/algorithm-oriented person wanting a shortcut to visual style. This site is full of these, in many areas of endeavor. As a musician, I particularly notice posts that do this kind of thing with music ("I've Invented a New Musical Notation That Makes Everything Easier!").

I just get sad for the designers who have to battle this stuff every day. No programmer would take "input" on their code from a nurse (say), but designers face "input" on their decisions and their craft at every turn. I've yet to meet a designer who was longing for a web form to input a bunch of numbers to generate some type sizes.

But I could be wrong. It happens a lot.

Maybe, but in this context on this site I think it's safe to assume a lot of people are going to look at this with "ah! another subjective judgment that can be marked Objectively Correct by using an algorithm."
When can I get a total replacement of CSS with something more sane? Seems like one of the few pieces of the stack that's just not getting any better over time. And no, flex isn't better.
I have no idea how you get to this from the article or the discussions in this thread. What do you propose to replace CSS with? How will it avoid the problems you perceive with CSS while still being useful?

(I’m genuinely curious what you think is wrong with CSS, and how it could be fixed. I’ve heard this kind of sentiment from time to time, and never had a reasonable answer. CSS certainly isn’t perfect, but it’s not at all bad, and most criticisms of it like the meme “CSS is awesome” box with overflow genuinely come from not understanding it and why any other approach would be worse.)

> What do you propose to replace CSS with

I don't think I need to have a solution prepared to define a problem?

> How will it avoid the problems you perceive with CSS while still being useful?

How did <insert any language> replace <insert any older language> while still being useful?

This is kind of what I mean when talking about CSS. For whatever reason, all of the innovation, invention, tinkering, progress that went into _every other aspect of software_ just gets forgotten about with regard to CSS? This idea that CSS is the perfect solution, or close enough that there's no reason to invent something radically different. We're on our 5000th Javascript build tool but we still just have terrible old CSS.

> and never had a reasonable answer.

Completely reasonable answer: I have no idea, it's not my responsibility to create a solution. CSS is enough of a problem that I just generally refuse to use it. I'm not alone in this.

I was hoping it was for baseline rhythm, something CSS needs badly
Why?

(Honest question. I’ve toyed with it in minute detail a couple of times over the past decade, but for fun or as part of matching a lined-paper æsthetic. Not because I think there’s any inherent virtue in it, because I don’t. So I’m curious why you think CSS needs it badly.)

Because the current methods to it are very complicated and only work with a few fonts. A reliable baseline rhythm would lead to better typography and sense of visual order.

More calm More orderly Easier to read More professional

Just a bug I noticed: the lowest two sizes (0.64rem and 0.512rem) displayed on the settings panel, are not part of the outputted CSS.
The tool currently generates CSS where the font sizes are assigned in descending order to h1, h2, h3, h4, h5, and h6 tags. However, this approach may lead users to mistakenly assign the h1 tag to the largest heading, rather than the most significant one. According to W3C accessibility criteria, HTML offers six levels of headings, with h1 being the most important and h6 the least important. It's crucial to adhere to these guidelines for optimal accessibility.
https://web.archive.org/web/20230325144112/https://typescale...

P.S. CDNs can keep your site up at near zero cost.

This is so helpful, wow! Thank you!