# Considered Type

> Most web typography is never decided, so I wrote a skill that decides it. Designers keep their decisions; everyone else gets the ones they were never taught to make.

- URL: https://www.digitaltableteur.com/blog/considered-type
- Author: Petri Lahdelma
- Published: 2026-11-02
- Read time: 10 min read

![](https://www.digitaltableteur.com/blog/considered-type/hero-composing-stick.webp)

Nobody finishes a good book and praises the leading. Readers notice that the evening went by, that the argument was easy to follow, that they never lost their place. The type did its job by staying out of sight, which is the whole job.

On the web the same invisibility works against us. Because nobody notices good type, nobody notices when it’s missing either. A page can be hard to read for reasons no one in the room can name. In October I pointed a new typography tool at my own blog. The paragraphs ran 104 characters a line, about half again what a comfortable line holds, on the site of a designer who writes about getting the details right. Nobody had chosen 104. It was what the layout left over.

That gap is what this article is about: the difference between type someone decided and type that fell out of defaults. I’ve started calling the first kind **considered type**.

Considered type is a decision made for this text, in this face, at this size.

The tool that found my 104 characters is Measured Type, an agent skill I wrote in late October and published as an open repository. It gives coding agents the decisions a typographer would make, grounded in Robert Bringhurst’s *The Elements of Typographic Style*. It also gives them the means to check those decisions in a real browser. This is what it does, who it helps, what writing it taught me and where it still falls short.

## Defaults Are Decisions Nobody Made

Every web page starts with typographic decisions already made. The browser picks a size, a template picks a font stack and a line height, a component library picks the spacing under headings and the layout grid decides how wide a paragraph can run. None of those choices were made for your text. They were made for every text, which in practice means for none in particular.

Coding agents inherit the same defaults and add one of their own: the average of everything they have read. Ask an agent for a fluid hero heading and you will usually get the same formula, give or take a decimal, because that formula is common on the web. Ask for an article page and you’ll often get sensible-looking CSS with no measure, straight quotes, hyphens where dashes belong and figures that stand up out of the sentence. It looks finished. Nobody decided it.

I want to be fair to the people who ship this, because I’ve shipped it too. A frontend developer implementing a design has a hundred things to get right and typography is rarely on the ticket. A founder building a product with an agent has no reason to know what leading is. A design system team can specify a type scale and still watch every product team set their own line length. Defaults are a rational response to having other work to do. The cost lands on readers, who can’t name what’s wrong and simply read less.

## What Considered Type Gives a Reader

The benefits are the old ones; they haven’t changed since metal type. A line of 45 to 75 characters lets the eye find the start of the next line without hunting. Leading a little more generous than the letters seem to need holds the place. Space under a heading that is smaller than the space above it ties the heading to what it introduces. Quotation marks that curl towards their words, dashes in ranges and real small caps for acronyms stop the reader’s eye from snagging on the punctuation. Figures that match the height of lowercase letters let numbers sit inside a sentence.

None of these are things a reader will thank you for. They are reasons a reader keeps going.

![The same short article set twice at a 1280 pixel window. Above, with defaults: a system sans at 16 pixels, paragraphs 167 characters wide, straight quotes, a hyphen in 1990-2005 and full-height figures. Below, set with Measured Type: Iowan Old Style at 18 pixels, a column averaging 66 characters a line, curly quotes, an en dash in 1990–2005, text figures that sit at lowercase height and small caps for CSS and HTML.](https://www.digitaltableteur.com/blog/considered-type/fig-article.webp)

*One article, two settings. The skill solved the column width in the browser: 30.5em gives 66.2 characters a line where the defaults ran 167.*

The skill works through those decisions in order. It first classifies the text, because reading text, display text and interface text follow different rules. Book rules applied to a button are their own mistake. Then it settles direction and language, so every rule is written to survive a right-to-left or vertical edition. Then it decides, citing the Bringhurst section behind each choice. Last, it measures whatever can be measured: characters per line in the face that actually rendered, how much the text grows at 200% zoom, contrast in light and dark schemes, whether the font really contains the small caps the CSS asks for.

That last step is what moves the work from advice to evidence. Anything the skill can’t check (Safari and Firefox rendering, for example, when it only has Chromium) goes into a list headed **Not verified** instead of being passed in silence.

### Considered in Every Language

Typography is where localisation quietly breaks. This site is published in English, Finnish and Swedish. Finnish is the hard test: compound words like *käyttöliittymäsuunnittelija* (user interface designer) run longer than a phone is wide. The language also has its own quotation marks, decimal comma and way of writing times.

![A short Finnish text set twice at a 375 pixel phone width. Left, with defaults and no language declared: the heading’s long compound word runs off the right edge of the screen, the range uses a hyphen, the percentage is written 3.5% and the time 9:00-16:00 with straight quotes. Right, set with lang fi and a smaller heading: the compound breaks at a syllable with a hyphen, the range takes an en dash, the percentage is 3,5 % with a space that cannot break, the time is klo 9.00–16.00 and the quotes are Finnish closing-style marks.](https://www.digitaltableteur.com/blog/considered-type/fig-finnish.webp)

*The same Finnish text at 375px. Declaring the language gives the browser its hyphenation dictionary; the rest is punctuation the language expects.*

With `lang="fi"` on the page the browser hyphenates by Finnish rules, so the heading breaks at a syllable instead of pushing the layout sideways. The audit called the default version a block: the page was 482px wide on a 375px screen. The fix is one attribute, a smaller heading and a few lines of CSS, which is the pattern I keep seeing. Considered type is rarely expensive. It’s just rarely anybody’s job.

## Who It’s For

I wrote the skill for myself first, but the people it helps most are the ones who don’t think of themselves as typographers.

### Designers

For a designer the benefit is that decisions survive. You can specify a measure, a scale and a heading rhythm in Figma and still watch them erode through handoff, refactors and agent edits until the shipped page has none of them. With the skill in the agent, each change is checked against the same rules you would apply. The review comes back in a language you can argue with: a rule ID, a severity, the measured value and the CSS that fixes it. “This feels cramped” becomes a finding that cites `§2.2.1`. A finding can be discussed in a pull request; a feeling can’t.

### People Without a Designer

Frontend developers get reasons instead of taste. When the audit says a paragraph runs 167 characters, it also says why that’s a problem and gives the width that fixes it, solved in the browser for the font that actually loaded. Founders and product managers building with agents get considered type without having to learn the vocabulary first; in testing, the skill loaded on its own for nearly every task that touched how text sits on a page. Writers and editors get their words set the way they meant them, with real quotes and dashes for their language and lines short enough that a long piece gets read to the end.

### Design System Teams

For a system team, one report format means one gate. The linter exits with an error while a HIGH finding remains. Run with `--diff`, it checks only what a branch changed, so an older codebase can adopt it a pull request at a time:

```bash
node path/to/measured-type/scripts/lint-css.js src --diff origin/main
```

It also splits the work cleanly with [Rhythmguard](https://github.com/PetriLahdelma/stylelint-plugin-rhythmguard), the Stylelint plugin I maintain for spacing scales. Rhythmguard keeps every size on the scale; Measured Type decides whether the scale reads well. Its type-scale script writes tokens Rhythmguard reads directly. Neither tool finds what the other does.

Product interfaces fail differently from articles. Nothing in a dashboard is too long to read, but numbers are hard to compare when they don’t line up, labels in small capitals crowd together and status carried only by colour disappears for anyone who doesn’t see that colour.

![A five-row service health table set twice. Above, with defaults: request counts and latencies left-aligned in proportional figures so their last digits end at different points, 11 pixel uppercase headers with no letter spacing in light grey, status shown only as coloured dots and a pale 10 pixel footer. Below, set with Measured Type: numbers right-aligned in tabular figures so place values line up, tracked 12 pixel headers in a darker grey, status written as Running, Degraded or Down beside each dot and a readable footer.](https://www.digitaltableteur.com/blog/considered-type/fig-dashboard.webp)

*The same table. In the default font the digit 1 is 26.5% narrower than 0, so 411,108 and 880,017 could never line up until the figures were made tabular.*

The audit blocked the default table on four HIGH findings: header text at 3.54:1 contrast, a footer at 2.23:1 and a table that forced a 401px page onto a 375px phone. The considered version passes with the same data, a word beside each status colour and one wrapper that lets the table scroll on its own.

## Writing Taste Down

The hardest part of building the skill wasn’t the code. It was turning a designer’s eye into rules an agent can follow and cite.

I started from my own notes and from Bringhurst, whose numbered sections gave every rule a stable name. That numbering matters more than it looks: a review that cites `§2.1.2` can be checked against the book, while a review that says “too wide” can only be believed or ignored. Translating the rules to the web meant rewriting most of the CSS that usually accompanies them, because much of what circulates as web typography advice predates logical properties, `text-wrap` and variable fonts.

Then came the uncomfortable part. Writing taste down forces you to label it. The skill’s taste reference marks every opinion as one of four kinds: a standard, a measurement, a convention or a preference. Some of my strongest habits turned out to be preferences. Others were conventions I’d adopted so long ago that I’d stopped noticing they were mine, such as how much a heading should still grow at 200% zoom. The skill now says which is which; a house style can overrule the last two.

The other discipline was length. The main instruction file has a budget of 2,300 words, enforced by a test, so every new rule has to earn its place by pushing an older sentence into a reference file or out of the skill entirely. A designer will recognise this as editing. It’s the same work as cutting a type scale down to the sizes you will actually use.

Every script was written test first, against 23 numbered specifications so far. The evaluations were registered before they ran. That sounds like ceremony for a typography tool. It is the only reason I can tell you which parts work.

## Pointing It at My Own Site

The first real job was the site you’re reading. Beyond the 104-character blog paragraphs, the audit found case studies running 104 to 139 characters a line and display headings that barely grew under zoom. We added one token, `--measure-reading: 30em`, then applied it to article prose, case study paragraphs and FAQ answers. The blog now averages about 65 characters a line; this paragraph is one of them.

The site also found faults in the skill. The first full audit of 14 pages reported 81 HIGH findings. Most were the tool misreading the page: text waiting to fade in on scroll was measured at full transparency and reported as invisible, icon-only buttons were reported as truncated labels and text meant only for screen readers was counted as clipped. Fixing the tool, with a test for each fault, brought the list down to 11 real findings. Dogfooding is a tired word for it. In practice it meant the site and the tool kept correcting each other for days.

## What It Doesn’t Do

The evidence is the part I’d read first, so here is the short version. On cases written after the skill’s content was frozen, runs with the skill and runs without it scored almost identically: current models already know most of the rulebook. Where the skill pulls ahead is measurement. On a held-out task asking for 62 characters a line in Charter, runs with the skill landed on average 0.18 characters from the target, against 0.82 for runs given a one-sentence hint and 0.43 for runs with neither, a difference from no skill too small to call. On fluid headings under zoom, that one sentence of advice matched the skill on its held-out case. Most of the measurable gain comes from the tools. A good model with a browser and the right question gets surprisingly far without me.

It costs something. Runs with the skill used 7% to 25% more tokens and up to twice the time. Every evaluation ran on Claude models; others are untested. The rendered audit needs Playwright and a Chromium download; without them the skill estimates and says so. It doesn’t judge font pairing or brand fit beyond its taste notes, it doesn’t draw fonts or logos and its coverage of Chinese, Japanese and Korean is a set of pointers. The text is licensed CC BY-NC 4.0 and the scripts MIT. Whether paid client work may use the text is a question I haven’t settled yet.

Every result, including the ones above where the skill lost, is in the repository with the run files that produced it.

## Try It

If you have Claude Code or another agent that reads skills, one command installs it:

```bash
npx skills add PetriLahdelma/measured-type --skill measured-type --agent claude-code -g
```

It also installs as a Claude Code plugin from the repository’s own marketplace. Then name it for your first task: *Use measured-type to audit the typography in styles.css and fix the HIGH findings.* The measuring scripts are optional; the README explains how to add them.

You’ve just read about 2,200 words at around 65 characters a line, with curled quotes, dashes where dashes belong and space under each heading smaller than the space above it. You probably didn’t notice any of it. Somebody decided all of it. Now your agent can too.

*Measured Type is on [GitHub](https://github.com/PetriLahdelma/measured-type). Corrections and wrong results are the most useful thing you can send.*