Typescale: A tool for easy CSS typography | Hacker News Reader

Typescale: A tool for easy CSS typography

typescale.com

147 pointssurprisetalk73 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.

> But at that point you have only about four usable values, and where was the virtue in using a scale for them?

The virtue was in drastically reducing the space of correct answers.

How long would it take the average developer to pick sizes out of an infinite number of sizes? And how long would it take them to pick sizes out of a small number of sizes?

I know I do not want to fiddle with an infinitely large problem space.

It reduced the space by arbitrary choice. You are just as capable of arbitrarily choosing four numbers as one ratio. I believe in you, though I don’t know you. In fact, I believe you will do a better job in your arbitrary choice of four numbers than in your choice of one scaling factor.

Although the four values from φ are usable, they’re unlikely to be excellent for the purposes of anyone in particular. You can easily choose more suitable, and will if you consider your content and intended design rather than just slapping a number on it.

> Although the four values from φ are usable, they’re unlikely to be excellent

I am not a designer. Excellence is not for me by any stretch of the imagination.

It sounds like you have not yet figured that one out for yourself and are maybe severely misjudging your own capabilities. It is just absolutely, completely bonkers to suggest anybody can "easily" pull off "excellent" rhythm, space, dimensions, design.

"Just pick up the saxophone, wiggle your fingers, and off you go, Coltrane!"

What in the actual what are you talking about

Very well then, I shall call the four values from φ lacklustre and uninspired; yet people have occasionally presented them as though they have objective value or virtue, which I deny. I say that if you possess the wherewithal to choose that value to compute your font-sizes from (which is far from trivial, and there’s no reason why you would think it’s any good unless someone told you it was and you believed them), you can choose four values that look good to you, possibly based on recommendations from others just like you surelyl did with φ, and get a result that is likely to be at least as good.

We’re comparing font-size values for headings, not anything more in the design. I didn’t say anything about pulling off excellent rhythm, space, dimensions or design, nor would I.

The default font size is 16px. You can scale it down to 12px for mobile viewport sizes and up to 18px for extra large and then use relative sizing for everything, including the text size of all the elements on your page.

There's a well known book called The Elements of Typographic Style that deals with text size (among many other things.)

This scale isn't helpful because it's arbitrary and based off of math percentages. And the actual values are just decimal values. 1.25, 1.33, etc...

It's not any better than eyeballing, and could in fact be worse, where a heading size might actually look better at 1.3rem instead of 1.33rem but because you're forcing yourself to stick to math you are using a size that is slightly too big.

And if you are looking for someone to have done this work for you, I'd recommend using Tailwind which has good sane defaults for many elements of typesetting:

- https://tailwindcss-typography.vercel.app/

- https://tailwindcss.com/docs/typography-plugin

> The default font size is 16px.

No, it’s not. You don’t statically know what the default font size is, because it depends on various user configuration and document language. For English text, it’s mostly 16px, but there are devices where the default is higher or lower.

> You can scale it down to 12px for mobile viewport sizes

Please don’t. I’d advise against going down to even 15px; 12px is madness, you should basically never have any text that small.

> I'd recommend using Tailwind

Eh, dubious for web sites. Tailwind is very clearly designed for and targeted at apps, and makes all kinds of decisions that are not suitable for general-purpose websites. It’s not terrible, since there have been enough people wanting to use it for general-purpose websites that they’ve made it tolerable, but it’s still going to be at least mildly painful to work with, because its actual defaults are deliberately extremely stupid, and adapting it to this kind of work requires effectively overriding quite a lot of stuff. (Disqualifier: I’ve never actually worked with Tailwind in anger, because I hate most of its defaults and near-defaults, and it just doesn’t match how I like to work philosophically, which is a pity, because I could quite enjoy working with something not far off it for some purposes. But a lot of the way it treats things like colour and dark mode is just objectively a terrible way of doing things—they designed themselves into a corner and insist on using tools they designed like an abundance of modifiers, even when they’re clearly inappropriate.)

I'm not going to respond to most of what you wrote, but the main point of my comment is that it is generally accepted practice to size text along a scale, when deciding different text sizes in a document, and Tailwind's text sizing defaults with their typographic plugin are widely used and considered acceptable.

You don't even have to use Tailwind, simply open the demo and look at how they scale the text size and line height on different elements. You could pull the computed styles from your browser.

You and I agree that using arbitrary numbers is pointless. You clearly have a lot of other strong opinions I don't care to debate with you about.

I am using Tailwind. It is great.

Yeah, that’s probably true. I only use 3 levels of headers on my website.

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.

Font sizes get scaled in the browser. So when you ask for a 9px font, the browser treats that as 9px in virtual pixels, then maps it into 18px physical pixels.

It mostly works, but gets weird when you have non-scaled content in the design.

Ah, that could be the misunderstanding.

You don’t have non-scaled content in the design. Everything is scaled. <img width="32" height="32"> will be 32px (as in, CSS pixels) wide, whether that means 32dpx (device pixels) or 64dpx or something else.

(OK, so there are a few escape hatches; you have things like <img srcset> which allow you to choose different image sources for different scaling factors, and you can also query devicePixelRatio and change things based on it—though all of this isn’t actually guaranteed to map to physical pixels, e.g. my system uses 1.5× scaling but Firefox hasn’t finished implementing fractional scaling under Wayland so it renders at 2× and then scales down to 1.5×, so any line that is carefully made “one device pixel wide” will actually only be ⅔ of a device pixel.)

In browsers, there are supposed to be roughly 72px per inch. This should get scaled, assuming the OS/Browser knows what the actual pixel density per inch is. And even then the scaling may not be linear to reality.

If you've ever run a mobile device without the real dimensions set properly (cheaper models, or custom roms) it gets interesting to say the least. Having less than stellar vision up close, I have every accessibility setting on my phone maxed... It's bad enough as it is the number of applications/sites that will render (in particular modals) off-screen.

In the end, however, nearly everything is scaled to either the real pixels, or often assume 72/inch as the actual screen density and scale accordingly. You really never know which.

Correction: The CSS units are defined as 96px = 1in. It’s the point that’s 1⁄72 inch.

My comment elsewhere in the thread is relevant on these units and how they’re anchored: https://news.ycombinator.com/item?id=36001822.

Yeah, I often get the two conflated... in either case, it's never, or at least rarely accurate.

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

Only partly, and not the part that dtagames was speaking of.

There are three families of distance units.

One is absolute length units <https://www.w3.org/TR/css-values-4/#absolute-lengths>. px is the canonical one of these, but it may be anchored to physical measurements (typical in print) or the reference pixel (which in practice is generally approximated by some number of device pixels multiplied by a scaling factor from the operating system).

Then you get viewport-percentage lengths <https://www.w3.org/TR/css-values-4/#viewport-relative-length...>, of which I will not speak, save to note that they’re broken by design so that they’re almost completely useless for layout purposes.

Then you get font-relative lengths <https://www.w3.org/TR/css-values-4/#font-relative-lengths>. The em dtagames speaks of is one of these. The root em, rem, is commonly used as a base, and is most commonly 16px, but it depends on a variety of factors like user preferences, the root font-size, the root font-family, and the root language. It’s very messy and even mildly context-dependent.

Most lengths should generally be font-relative for most perfect compatibility and user-preference-acceptance, but doing this perfectly is harder than it may sound.

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.

Love that rounded font! And the site looks great.

I just changed an H2 tag to an H3, and it looks like your H3 is way too small.

One thing I've seen for H3 and below is to use `font-style: italic` and font-weight 500 to distinguish it from the H2. I don't think that would work for your site though.

For your site, you could maybe throw a `color: #444` on H3 and below? You can also try `h1, h2 { margin-left: 1em }`.

Ah, that's because my static site generator only includes "needed" CSS directives, so if the page doesn't have h3 then this isn't included (I know, classic premature optimisation):

    h3 {
      font-size:2.074rem
    }

Playing with font weights or color is a good suggestion, thanks.

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.

I think you assume that a designer can't also understand math, ratios and scale. Many practical designers are also engineers.

Not sure how you read that into my comment. I'm saying that trained, skilled designers don't need formulas and tools like this to achieve pleasing and functional results.

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.

What do you even find wrong with CSS? You haven’t defined the problem at all.

1. Positioning (yes even with flex) is unintuitive and painful

2. The fact that the !important tag exists, and at a broader level the fact that cascading exists

3. The community seems pretty hellbent on rejecting working solutions for being "bad". float: left is "bad". And yet, many/any other positioning systems are, to me, much worse. So to me, it's all "bad". Similarly, tables are the easiest way to position things correctly (since point 1, all other positioning tools are pretty bad), and yet, table-based-layouts are "bad". So again, it's all "bad".

More elegantly put:

- https://adamwathan.me/css-utility-classes-and-separation-of-...

- If you search "What's wrong with CSS y combinator", you'll get some derivative of this exact conversation over and over again for the past 15 years. CSS people saying "no it's good!", many other types of people saying "it's just too complicated and I don't want to keep doing it", followed by css people saying "no it's good!"

I think Tailwind is probably the closest approximation to tolerable CSS, but I also think its existence highlights a greater problem with both the community and the technology.

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

Ah, I think you copied the list from https://zellwk.com/blog/why-vertical-rhythms/. It says these might be properties of “better”, largely without quantifying what they mean, as part of comparing something with simple rhythm (and quite ugly in its spacing, in my opinion) with something that’s deliberately terrible.

To the best of my knowledge, no one has treated “rhythm” in any way rigorously, and it’s mostly just a crock, something that sounds good on paper but is utterly without actual reason or value, rather like modular scales for typography.

I don’t respect that article. Its analogies are lousy, its examples of non-rhythm unnecessarily bad (straw-man arguments), its rhythm not great in any case (and lacking any attempt at anything like baseline alignment), and after the first instance it only really shows rhythm with an unrealistic superimposed grid which obviously makes rhythm look better than non-rhythm. I get the sense that the author has read a bit of various things, and then attempted to justify an opinion in any way they could, and ended up producing an incoherent and completely unsound argument.

There are certainly major places where consistent spacing and sizing is of value. But slavishly following it page-wide without something like a background pattern that you’re aiming to match (which is absolutely a legitimate use case, but is æsthetic rather than functional)… I’ve never come across any argument that seemed to hold any water, and I’d like to understand why a few people are so attached to the notion that it has inherent virtue.

To the best of my knowledge, no one has treated “rhythm” in any way rigorously, and it’s mostly just a crock, something that sounds good on paper

Ironically it does sometimes look better on paper - specifically on cheap, thin paper with double-sided printing where ink showing through from the reverse side in the inter-line gaps can be distracting and unattractive.

So perhaps you're wrong about it being utterly without reason? It makes sense to maintain an exact vertical rhythm in digital typography any time you're displaying your content on a thin, double-sided monitor where the image from the reverse side bleeds through. Not sure how much use it is apart from that though.

Amusing indeed; I was actually thinking about my primary Bible at the time, which certainly benefits from rhythm, including having things like book titles and page headers fit the rhythm. Paginated media can certainly benefit from rhythm, most obviously when double-sided with bleed but even when not, as you flip through.

I meant “no value in scrolled media”, I just didn’t express it so because I hadn’t thought it through carefully enough. Note that digital media can also be paginated; a PDF where you switch pages rather than scrolling, for example, or content that might even normally be scrolled but viewed on an e-book reader, due to the physical properties of e-ink panels; and these things can definitely also benefit from matching alignments and dimensions across pages even without the bleed issue.

Still, even though I was expressly thinking about it, I somehow didn’t connect the dots that maybe this idea of rhythm is a carry-over from the print era. Thanks for pointing out that link!

(My primary Bible is a second edition RSV, where the layout of the first edition was reused and only tweaked where necessary. This leads to minor ink weight differences within some pages, and a very few instances of visibly wonky layout, with elements a fraction of a millimetre from where they should be, or slightly crooked. The most significant weirdness for rhythm purposes is how John 7:53–8:12 was restored from a footnote to the main text, and the column it’s in has one fewer line than normal, with a half-line break between two paragraphs, and the rest of the line’s height distributed through the column’s leading. I’ve been paying a lot of attention to its typography recently, as I start making my own software designed for Bible reading, which is basically a space where there has never been a single option that I would consider good.)

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!

Reply on news.ycombinator.com