Your comparison table is one sentence

We found this on our own site this week rather than reading about it. Nitaris publishes a page for marketing agencies with a nine-row table on it: one column for what every account can do today, one for what the agency workspace adds. Nine rows, two columns, a heading over each. When we split that page into the passages a reader would quote from it, the entire table came out as a single passage of 330 words. Every other page on the site tops out at 209 words per passage, and the typical page's longest is 92. The table was not long. It was nine separate things with nothing in between them.

A grid you can see is not a grid in the text

The cause is dull and close to universal. HTML has a real table element with real cells, and every browser has supported it since the beginning. Hardly anyone reaches for it now, because making one behave on a narrow screen is awkward, so the modern way to build a comparison grid is a stack of generic containers with a layout rule applied over the top. On screen the two are identical, and the second is usually better. Underneath, the difference is total: a real cell ends, and a generic container does not.

You can check your own in about a minute, and it costs nothing. Open the page, select from just above the table to just below it, copy, and paste into a plain text editor — anything that strips formatting. If rows land as rows, you have a table. If what lands is one unbroken paragraph reading “Starter Pro Enterprise Users 3 25 Unlimited Support Email Priority Dedicated”, then that run of words is what every reader of your page that has no screen receives. That is not an exotic audience. It includes the thing that writes your search snippet, anything summarising your page, and anyone using a screen reader.

The condition at the top stops reaching the bottom

This is where it stops being tidiness. Comparison tables carry their conditions in the headings, almost by definition. “Pro plan”. “Billed annually”. “Add-on”. “From”. “US only”. “Coming soon”. The convention is sound for someone looking at the page, because the eye holds the column in view while it travels down the rows. For anything working on text alone, that heading is just the first two words of a very long sentence, and by the time the eighteenth cell arrives the column it belongs to is hundreds of words behind it.

Ours was an exact instance. Both of our columns were labelled at the top — one said every account, the other said early access — and nine rows of capabilities followed. Lifted out as one passage, the two labels appear once at the start and then eighteen cells follow in alternating order with nothing marking which belongs to which. Someone reading only that passage, wanting to know whether client review links are something they can use today, could not tell. The passage is the unit that travels, so the answer has to survive inside it.

It is worth being precise about what went wrong, because the obvious diagnosis is the wrong one. The passage was not too long. A 209-word paragraph elsewhere on our site is a perfectly good passage: one person wrote it as one thing, and anything lifting it lifts what was meant. Our table was not too long, it was too many — nine authored items with no boundary between them. A word limit would not have caught it, and would have started firing on honest paragraphs instead.

Put the condition in the cell

There are two fixes and you want both, because they fail in different ways.

• Structural. Make the table a table: a real table element, real header cells, real data cells. If the layout truly cannot survive it, the cheaper version is to wrap each cell's text in a paragraph element inside its container. It changes nothing visually and it restores the boundary, which is the only thing you were missing.
• Editorial, and this one is worth doing even if you never touch the markup. Repeat the condition inside the cell. “Early access: client review links under your own name.” “Pro plan only.” “From £12 a month.” It reads faintly redundant on screen, and that mild redundancy is the usual sign that a sentence is carrying its own context rather than borrowing it from its neighbours.

The editorial half is the one that keeps working when something changes. Markup gets rebuilt — ours was, which is how the table arrived in that state in the first place, during a redesign that was in every other respect an improvement. A condition written into the sentence travels with the sentence through every rebuild after it. A condition that lives in a column heading survives exactly as long as the column does.

The general shape is the one worth keeping, and it is not new on this blog. We have written about how your later collection pages get thinner once a set is big enough that nobody reads it as a set, and about why a promise is harder to check than a number. This is a third turn of the same thing: in each case what would have shown you the problem is a view that exists, is cheap to open, and that nobody has a standing reason to open. The grid is fine on screen. You have to go and look at it with the screen taken away.