Build WordPress Tables That Stay Useful on Mobile

A wide comparison table and a phone screen serve different reading tasks. On desktop, readers can scan columns. On mobile, they may need the details for one row without repeatedly scrolling back to its headings. In a WordPress table shortcode, I kept one dataset but used a comparison table at wider widths and expandable row details on small screens. The implementation also had to handle different column counts, rich cells, older markup, and invalid editor input. The important question was whether readers could still connect every value to the right label in either view.

Choose the mobile reading pattern

Wide tables are excellent when a reader wants to scan down a column and compare across rows. Shrinking that grid until every cell becomes unreadable preserves the HTML but destroys the task. Horizontal scrolling can help, yet an eight-column schedule still makes a phone reader remember headings that have disappeared off screen.

I kept semantic table markup for larger viewports, including a sticky first column and horizontal containment when the content genuinely needed it. Below the mobile breakpoint, each row becomes a compact disclosure. The row label stays visible, data labels move beside their values, and the reader opens only the item they need. It is the same information, but the interaction matches the screen.

Validate rows against the column headings

The shortcode accepts pipe-separated headers and any number of nested rows. Simple rows can use pipe-separated values; richer cells support alternatives, notes, pills, formatted content, and intentional blanks. That flexibility creates a validation rule: every row must resolve to the number of data columns promised by the headers.

I chose to fail closed. If the title, headers, rows, or dimensions are invalid, the renderer returns no partial table. A broken half-table can look authoritative while associating a value with the wrong heading. An empty result is easier to detect in review and safer than plausible misinformation.

Keep essential content available without JavaScript

The mobile rows use keyboard-operable checkboxes and CSS state, with first, all, or none as the default-open policy. That avoided making essential content depend on a JavaScript bundle. It also kept the component usable in previews and unusual embedding contexts where the theme script might not run.

I used native controls and CSS for the current open-and-close behavior. More complex interactions could still justify JavaScript. If the component later needs synchronized analytics, deep links, or cross-row controls, script may earn its place. For the present interaction, native controls and CSS are the smaller failure surface.

Preserve older markup and styling

There was already reviewed raw markup using the same established CSS classes. Replacing it with an entirely new component would have created two systems and a migration project. Instead, the shortcode emits the established class names, and the complete component styling lives in the theme so old markup and new authoring share one runtime.

A reusable component is not only a nicer way to create new content. It is a promise about how existing content keeps working.

That promise affected names, CSS ownership, preview behavior, and the decision not to rewrite saved posts.

Test content variations at different widths

I did not test one happy table at one phone size. Fixtures covered three-, six-, and eight-column variants; simple and advanced cells; empty slots; primary and secondary time labels; footer notes; and malformed dimensions. Browser coverage ran across several phone widths, tablet, and desktop, while PHP tests exercised parsing and escaping.

The test question was never merely “is it visible?” On desktop I checked semantics, sticky labels, containment, and alignment. On mobile I checked the default-open policy, keyboard operation, data labels, hidden empty cells, and whether expanding one row exposed the correct values.

One subtle issue was editorial preview. A shortcode that behaves well only on the public template is difficult to review, so I kept the same CSS classes available to isolated admin previews. Editors can see the column relationships and richer cell forms before publishing, while the public CSS remains the shared presentation. I did not try to reproduce every viewport inside the editing screen; the preview communicates structure, and browser verification owns responsive behavior.

I also documented literal pipes and mixed rich-cell syntax because editors need explicit examples of delimiter and escape rules. The authoring guide shows the simple path first and promotes nested cells only when content actually needs them. Editors should be able to create an ordinary three-column table without learning the advanced syntax.

Document how editors should create the table

• What comparison task does the wide layout support?
• What single-row task matters on a phone?
• Which content forms are allowed, and how are dimensions validated?
• Can essential content remain available without JavaScript?
• Which existing markup or saved content must remain compatible?

Before choosing a responsive pattern, decide what readers need to compare on desktop and find on mobile. Validate column counts and label relationships before rendering. Test short and long cells, intentional blanks, keyboard use, and the default expanded state. Explain the simple authoring format first, then document richer cell options with examples. If older posts use the component’s classes, include them in the checks so a new shortcode does not unexpectedly change existing tables.

Photo by Pixabay on Pexels.