[Library] Compare and tables

Catalogue accessStandard

Compare matrix

A capability matrix in a core table: one row per capability, one column for each of the two plans people choose between, and a mark in every cell, with a third plan named in one line under the table instead of a fourth column that would ladder its row headers on a phone. The recommended column is announced by a two-pixel bracket that stands over it and hands off to the table's own hairlines, so nothing is filled and nothing is coloured. Three fixed columns hold roughly 117 pixels each at 390. States no colour and no font of its own.

Variation View
Before you copy
Open in a new window

Identical markup in every theme. Manrope typeface rgb(255, 255, 255) ground 1280px viewport

A capability matrix across a full-width band: a short left-aligned opening, then a core/table with one row per capability, one column for each of the two plans people choose between, and a single mark in every cell. A third plan is named in one line under the table rather than given a column of its own. It is the first table in this catalogue.

The signature moment

A bracket that stands over one column

The recommended plan is not filled, tinted or badged. A two-pixel rule comes down both sides of its column and across the top, in a bracket that sits immediately above the table and stops where the table starts, so the table's own hairlines carry the line on down the column. The mark is currentColor, so it is always exactly the colour of the words beside it, in any theme, and it can never resolve to a pale accent nobody can see.

Everything else in the table is held flat on purpose. Every cell is bordered by the same hairline, the head row is separated by the rule WordPress's own table styles put under a <thead>, and nothing is emphasised except by that bracket. A matrix that shouts in three places is a matrix nobody reads across.

What it inherits from your theme

  • Every colour. The band's ground and text are preset chains ending on a WordPress core default, and every rule in the table, its hairlines included, is currentColor, so the grid follows your text wherever your theme puts it.
  • The typeface. The pattern states no font family anywhere.
  • The table's own furniture: the cell padding, the hairline weight and the heavier rule under the head row are WordPress's table styles, which your theme is free to restyle.
  • The spacing scale, through core spacing presets.

What it decides for itself

  • The bracket, its two-pixel weight and the fact that it is currentColor.
  • The measure: a 1240px inner in a full-width band, with the opening held to 680px so the lede is not a wall of type across the whole table.
  • The table's type: a clamp() from 15px to 17px rather than the small preset. small is guaranteed to exist and is 13px in a theme with no size scale, and the cells of a comparison table are read rather than glanced at. The legend under the table states its own clamp for the same reason; small is kept for the two tracked capitals, which are glanced at.
  • hasFixedLayout, stated explicitly rather than left to the default. The default flipped from false to true between WordPress versions this catalogue supports. A table that states it in its own settings renders the same on both, and cannot be marked invalid the day the buyer's site is upgraded.
  • Seven rows, two plans in the table and a third in a line under it. The ticks form a staircase, which is what a comparison of tiers actually looks like when it is honest. The third plan is a sentence rather than a column because a phone cannot hold a fourth column without breaking the capability names into ribbons, and a table nobody can read across on a phone is worth less than a plain sentence.
  • The legend is held to 28rem, in a nested constrained group, so it lines up with the lede's measure instead of running the full width of the table.

What you change first

  1. The plan names in the head row, and the seven capability names in the first column. Keep them to two or three words.
  2. The marks, cell by cell. The staircase is a placeholder, not a claim.
  3. The line under the table. It names the plan that is not in the grid and says what it adds. Delete it if you sell two plans, and delete the rows that only the missing plan carried.
  4. Which column is recommended. Move the bracket by moving the group with the border into another of the three columns of the row above the table; the first column of that row sits over the capability names, so the plans are columns two and three.
  5. The bracket's label. "Our pick" is two short words so that it wraps inside a 117px column on a phone; a single long word will not.

If you do not want a recommendation at all, delete the whole three-column row above the table. Nothing else in the pattern depends on it. If you add a plan, add a column to that row in the same edit, or the bracket lands on the wrong plan and nothing will tell you.

What the marks are, and what a screen reader makes of them199 words

Each cell holds one real character, never an icon and never an image:

  • &#10003; (U+2713 CHECK MARK) means the plan carries the capability.
  • &#8211; (U+2013 EN DASH) means it does not.

Both are ordinary text in a font the visitor already has, so they inherit the table's size and colour and they survive a copy and paste into a plain document. The table is marked up so that the two characters have something to attach to: the plan names are <th scope="col"> and every capability name is <th scope="row">, which is what makes a screen reader announce a cell as "Studio, page templates, check mark" rather than reading a lone symbol out of context.

Be careful with the en dash. A check mark is announced by name in every screen reader we know of; a dash is punctuation, and several readers say nothing at all for it at their default verbosity. If the visitors you are writing for rely on a screen reader, replace the en dash with the word No (and, if you like, the check mark with Yes). The row and column headers do the rest, and nothing else in the pattern has to change.

What happens on a phone, and why there are only three columns357 words

The table is hasFixedLayout, so its three columns are exact thirds at every width: at 390 that is roughly 117 pixels each.

It carried four columns at first, and the fourth was measured out. Four quarters of a 390 phone is about 87 pixels a cell, and at that width the capability names in the first column laddered: "Core-block markup" set 9 characters per line over three lines, "Inherits your theme" 10 over three, in every theme tested. A row header broken into a ribbon of one word a line is not a table anybody reads across on a phone, so the count came down to the feature column plus two plans, which is the shape the phone can actually hold. The plan that came out is not lost: it is a line of copy under the table, and the two rows that only it carried went with it.

Two more things follow from the fixed layout, both of them WordPress's own doing and both deliberate here.

  • Long capability names wrap, they do not push the table wide. Core's table stylesheet sets word-break: break-word on the cells of a fixed-layout table, which is why every capability in this pattern is two or three words. Keep yours short and the phone layout stays a table rather than a column of hyphenated fragments.
  • The table can never give the page a horizontal scrollbar. Core puts overflow-x: auto on the figure, so a table too wide for the screen scrolls inside its own box. That is the safety net, not the plan: at 390 this matrix fits, and a fourth column will ladder its row headers before it ever scrolls. A scrollable box is not reliably reachable from a keyboard in Safari, so treat a scrolling matrix as a sign to cut a column.

The bracket over the recommended column is built from a three-column row that does not stack on mobile, so it stays aligned with the table's thirds all the way down to 390. The row always carries exactly as many columns as the table: that is the whole of how the bracket finds its plan.

Why the recommendation is not painted into the table108 words

core/table gives a cell exactly six attributes: its content, its tag, its scope, its alignment, and the two span counts. There is no class and no style on a cell, so a column inside the table cannot be given a border, a weight or a ground of its own without a stylesheet, and this catalogue ships no CSS. That is why the bracket sits above the table instead of around the column, and why the recommendation is a structural mark rather than a fill. If you are tempted to add a colour to that column in the editor, the block will only let you colour the whole table.

Back to the library

Continue exploring

Next in Compare and tables

Explore all 14 Compare and tables patterns