Where the alignment tool is wrong

The tool aligns boxes; the reader aligns shapes

Every layout tool aligns bounding boxes, because a bounding box is a rectangle it can compute. A reader aligns the visible mass of the marks. For plain rectangles these coincide, and for almost everything else they do not. The gap between them is where optical alignment lives, and it accounts for a surprising share of the difference between work that looks professional and work that looks nearly right.

Here are the specific cases, with the sizes of the corrections, so you know how much to nudge rather than guessing.

Overshoot in letterforms

A lowercase o is drawn slightly taller than a lowercase x. A capital O extends slightly above the cap line and below the baseline. A pointed A does the same. These overshoots are typically 1 to 1.5% of the size — about half a pixel at 40px, one and a half pixels at 100px — and they exist because a curve that stopped exactly at the line would look small.

You rarely have to do anything about this in text; the typeface designer has already done it. It matters when you set a single large letter or a numeral as a graphic element, or when you align a letterform against a drawn rectangle. Then you are working with the letter's outline, not its metrics, and you align what you see.

Hanging punctuation

A paragraph that begins with an opening quotation mark has a visual left edge further right than a paragraph that begins with a letter, because the quote mark is a small shape high up with white space beneath it. The traditional fix is to hang it outside the measure, so the letters line up and the punctuation sits in the margin.

The same applies to bulleted lists, where the bullet should hang and the text should align, and to hyphens at a right margin.

CSS has hanging-punctuation: first; and support is still limited to Safari at the time of writing, so in practice you do it with a negative indent:

blockquote p:first-child { text-indent: -0.4em; }

This is a good example of an honest limitation: the correct mechanism exists in the specification, is not widely implemented, and the workaround is approximate because the right offset depends on the typeface.

Icons beside text

An icon in a 24px box beside 16px text will look low when both boxes are centred. The reason is that text's optical centre is around the x-height, which sits below the centre of the line box, while the icon's mass usually fills its box evenly. The correction is small and consistent: shift the icon up by roughly 1 pixel at body size, 2 at larger sizes.

The second icon problem is optical size. A circle, a square and a triangle drawn to the same bounding box look like three different sizes — the circle smallest, the square largest. Icon sets built properly compensate by letting shapes exceed the nominal grid: in most well-made sets, circles are drawn a few per cent larger than squares. If you are mixing icons from two sources, this is the first thing that will look wrong and the hardest to name.

Text inside a button or a box

Set equal top and bottom padding on a button and the text will look as though it has sunk. The line box includes descender space that most words do not use, so the visible mass sits high in its own box and the space below it therefore looks larger.

The correction: reduce the bottom padding by 1 to 2 pixels at body size, or set the line height explicitly and pad against that. If your button contains a word with a descender — Category, Apply — the effect is smaller, which is why the same button can look right on one label and wrong on another.

The same is true of headings. A 24px gap below a heading is optically larger than a 24px gap above it, because the heading's line box carries half-leading above the caps. Headings almost always want more space above than below, and a symmetric setting reads as though the heading belongs to the paragraph before it.

Centring things with tails

A logo with a descender, a swash or a single tall ascender has its mass somewhere other than its bounding-box centre. So does any wordmark with an ampersand or a trailing full stop. Centre the mass. The practical method is to blur the thing heavily until it is a single blob, note where the blob's centre falls, and align that.

The workflow that survives other people

Align mathematically first, because it is free and gets you within a pixel or two. Then look. Then nudge. Then — and this is the part that gets skipped — record the nudge as a deliberate value rather than leaving it as a hand adjustment.

In code that means a named offset with a comment. In a design file it means a note on the component. Without it, the next person sees an element that is 1px off the grid, helpfully corrects it, and quietly undoes work they could not see the reason for. This happens constantly, in both directions, and the only cure is writing down why.

An optical correction with a reason attached is craft. The same correction with no reason attached is indistinguishable from a mistake, and will be treated as one.