Skip to main content

Home Writing

Where do you start measuring distance from when the origin is the bottom of a block of text?

To frame this post, I’d like to share a tweet by Irina Bednova:

This is one of those situations where everyone assumed their way of doing things is the way everyone does things.

The situation

The websites I work on have a lot of text content. Because of this, it is very common for a component to be placed after a paragraph.

Components tend to have a discrete outermost border. This makes it easy to understand the component’s boundaries.

Text is a little different.

When you place text on an artboard in design tooling, it provides four different “bottom edges” you can measure from:

The phrase ‘Sphinx of black quartz, judge my vow.’ A red line shows to the baseline. A purple box outlining the words ‘judge my vow’ shows the em height. A green fill on the bottom part of the letter y shows the glyph’s descender. A blue box outlining the entire phrase shows the bounding box. The phrase ‘Sphinx of black quartz, judge my vow.’ A red line shows to the baseline. A purple box outlining the words ‘judge my vow’ shows the em height. A green fill on the bottom part of the letter y shows the glyph’s descender. A blue box outlining the entire phrase shows the bounding box.

1. Baseline

In typography, the baseline is an invisible line that glyphs sit on. There’s a little more nuance to this, but this is a post about measurement, not typographic minutiae.

The word ‘onion’ with a blue underline demonstrating the baseline.

2. Descender

A descender is the part of a glyph that descends past the baseline. Letters like j, p, and q are all good examples of glyphs that utilize them.

The word ‘jackdaw’ with a green highlight on the lower portion of the letter j demonstrating the descender.

3. Em height

In CSS, em height is the total height of a font. This includes a glyph, its lowest descender, and additional negative space both below its lowest descender and above its highest ascender.

The word ‘cabin’ with a purple outline showing the em height.

4. Bounding box

A bounding box is the outermost bounds of a selection you have made in a design tool. It is typically represented by a thin outline, with squares on the corners to indicate the selected content can be resized.

The word ‘silver’ with a blue outline with square drag handles on each corner.

The confusion

At first blush, each one of these properties hypothetically makes a good origin point to start measuring from. However, there’s some nuance to consider:

Baseline

A baseline is a common thread that passes through an entire font. It is also invisible. If a design tool does not support highlighting the baseline (both Sketch and Figma do), it can be difficult to discover.

Descender

The bottommost point of a descender is easy to see visually, but descender length isn’t always uniform.

In addition, the bottommost point of many descenders’ overshoot doesn't always cleanly align to the pixel grid:

The letter g placed over a pixel grid, with a small red highlight on the bottom of the g showing how it does not align to a pixel grid.

Em height

Em height is also invisible, and therefore has the same issue as the baseline.

Em height is also variable between different fonts—there is no one “standard” proportion everyone must observe. This is by design and is due to each font’s aesthetic and functional needs.

This can get weird when multiple typefaces and font sizes are used, but a stakeholder expects a set pixel difference between visible between components as opposed to a proportionate scale value. There are some efforts underway to address this, but it's still a long ways off.

Bounding box

In most design tools, adding text to an artboard creates an editable object whose bounding box height is the same size as the font’s em height.

You can also manually adjust the height of a bounding box to be longer or shorter than the set text length. This is commonly done to express the minimum or maximum amount of content something can receive.

The text ‘The five boxing wizards jump quickly’ outlined in a purple em height box. Outside the purple em height box is a blue bounding box that has had its height dragged downwards.

Because of this, a bounding box’s size isn’t necessarily reflective of the content’s em height.

Smashing them all together

In our organization there are designers we know and speak with. There are also an unknown number of unknown designers outside our organization who consume our design systems.

The real issue is these websites are worked on by multiple people, and each person assumes the way they’re doing it is the way everyone else is doing it.

This creates a ton of variance in the distances between things, which creates divergence. This spacing divergence immediately becomes design debt.

There is also the assumption that each person uses one way to measure distance consistently in both a single design file and every single file they have, or will work on, which may not always be true.

Codification

A downstream effect is the developers who reference these design files may take one of a few approaches. Developers may:

Much like designers, there is also the assumption a developer will use the same measuring method consistently on the project, as well as projects they’ll work on in the future.

We also have a similar organizational situation for developers as we do designers. There are the developers we're aware of, as well as an unknown number of unknown developers outside our organization who consume our design systems.

What does this create and what can you do about it?

This is a great example of design tooling’s limitations around expression of intent.

The measured distance is an expression, and a lack of codification about one of the distance’s origin points manifests system-wide uncertainty. This uncertainty is distributed design and development debt that is extremely difficult to rectify.

You can (and should) collectively decide on a standard and document it, but documentation is only as good as people who read and practice it.

So what can we do about this?

I’m honestly not sure. Good onboarding practices, design system governance, design and code reviews, and scheduled design debt work can all help, but they’re all reactive.

If you know of good practices in this space, please let me know.

So, what do you measure from?

Baseline!

Published on Approach, Design, Design Systems, Development, Typography.

Navigation