iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
The most reliable WordPress design workflow treats the theme as a design system, not a pile of page-specific CSS. Put shared colors, typography, spacing, states and responsive rules in theme.json; enable block features only when the layout supports them; make the editor resemble the published site; and load block CSS only where it is needed. Finish with an accessibility and handoff review at real viewport sizes.
The techniques below apply to block themes and, with some code-based adaptations, classic themes. Version notes are included because WordPress has moved several design controls from legacy theme support and the Customizer into the block editor and Site Editor.
Recommended Free Tools
1. Make theme.json your design-system control center
theme.json was introduced as a settings mechanism in WordPress 5.8. It gives the editor and the front end one vocabulary for design tokens instead of forcing designers to maintain separate Customizer settings, editor overrides and scattered selectors.
Define tokens before styling individual blocks
Start with the values that should remain consistent across the site:
#1 Best Overall
- Preset colors for backgrounds, text, borders and accents.
- A type scale, including the intended line-height and which sizes are available to editors.
- Spacing presets for section gaps, card padding and inline rhythm.
- Element states such as link, button and heading styles.
- Layout widths, including the normal content width and wide width.
Presets generate reusable classes and custom properties that both the editor and front end can consume. A designer can change a token once rather than hunting through dozens of block rules.
A minimal token structure
{"version":2,"settings":{"color":{"palette":[{"slug":"ink","color":"#17202A","name":"Ink"},{"slug":"brand","color":"#1769AA","name":"Brand"}]},"typography":{"fontSizes":[{"slug":"body","size":"1rem","name":"Body"},{"slug":"display","size":"clamp(2.25rem,5vw,4.5rem)","name":"Display"}]},"spacing":{"spacingSizes":[{"slug":"small","size":"0.75rem","name":"Small"},{"slug":"large","size":"clamp(2rem,6vw,6rem)","name":"Large"}]}}},"styles":{"elements":{"link":{"color":{"text":"var:preset|color|brand"}}}}}The example is illustrative: choose values that fit your brand and content. Keep the token names stable so client editors learn a predictable vocabulary. If a control is not supported by your CSS, do not expose it merely because the editor can display it.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Use responsive keys deliberately
WordPress responsive styles provide base, tablet and mobile values. The documented defaults treat 480px and narrower as mobile, and widths above 480px through 782px as tablet; a theme can customize those viewport values. Responsive overrides can be scoped to the documented @mobile and @tablet keys. Tablet and mobile values do not automatically inherit from one another, so set the mobile value explicitly whenever it differs from the base or tablet treatment.
2. Enable only the block features your layout can honor
Many block controls are opt-in. Exposing a control without implementing its corresponding CSS creates a misleading editor and broken client content.
Wide and full-width alignment
In a classic theme, add_theme_support( 'align-wide' ) enables alignwide and alignfull layouts. In a block theme, configure the layout widths in theme.json and provide CSS that lets those blocks escape the normal content column without causing horizontal scrolling.
add_action( 'after_setup_theme', function () {
add_theme_support( 'align-wide' );
} );Test wide and full-width blocks inside nested groups, on narrow phones and when a scrollbar is present. A full-width image that is technically wider than the viewport is not a successful implementation.
Responsive embeds
add_theme_support( 'responsive-embeds' ) opts a classic theme into responsive aspect-ratio behavior for embedded content. Without that opt-in, an iframe or video may preserve a desktop width and overflow on small screens. Check social posts, maps and video providers separately because their own markup can impose additional constraints.
Spacing and link-color controls
Custom spacing and link-color controls also require explicit support or equivalent theme.json settings. Expose a spacing scale only when your components use the resulting values consistently. If links need a special treatment on dark sections, define the state in the theme styles rather than asking editors to add one-off colors to every paragraph.
3. Make the editor a trustworthy preview
A designer should not approve a layout in a canvas whose type, widths or spacing differ from the published page. WordPress supports editor styles so the editing canvas can use the same visual rules as the front end.
Load an editor stylesheet
Classic themes can declare editor-style support and enqueue a stylesheet for the block editor:
add_action( 'after_setup_theme', function () {
add_theme_support( 'editor-styles' );
} );
add_action( 'enqueue_block_editor_assets', function () {
wp_enqueue_style(
'site-editor',
get_theme_file_uri( 'assets/css/editor.css' ),
array(),
wp_get_theme()->get( 'Version' )
);
} );Block themes normally centralize these values in theme.json, but a small editor stylesheet is still useful for rules that cannot be expressed as tokens.
Match the three content widths
Set a main column width, a wider width for wide blocks and unrestricted width for full-width blocks. The editor canvas should show the same relationships as the front end:
.wp-block { max-width: 720px; margin-inline: auto; }
.wp-block[data-align='wide'] { max-width: 1180px; }
.wp-block[data-align='full'] { max-width: none; }Use the actual values from the site’s composition, not these example numbers. Compare headings, long words, buttons, pull quotes and image crops in both contexts. If the editor wraps a heading one line earlier than the live page, the preview is not trustworthy.
Use the editor preference that applies theme styles
The Preferences panel includes a “use theme styles” option. Turn it on during visual review so the editor resembles the published site. If a team member turns it off, they may judge default editor typography instead of the design system.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Rank #3
4. Design responsively at the block level
Responsive styles let a block use different settings according to the screen size at which it is viewed. Treat each block as a component with a base state and intentional tablet and mobile adjustments.
Choose what changes at each state
- Base: establish the desktop or broad-screen composition, readable line length and default spacing.
- Tablet: adjust columns, gap sizes, media ratios and navigation before the layout becomes cramped.
- Mobile: set explicit values for stacking, type size, padding and alignment. Do not assume the mobile value inherits the tablet value.
Review the documented defaults of mobile at 480px and below and tablet from above 480px through 782px, then test your theme’s customized breakpoints if you changed them. A breakpoint is a design decision, not a device-name checklist: inspect where your actual content stops fitting.
Keep content order and interaction intact
When columns stack, preserve a logical reading order. Do not use visual positioning to put a call to action before its heading for sighted desktop users while leaving it after unrelated content in the document order. Check keyboard focus, tap target spacing and captions after every responsive change.
5. Ship less CSS with block stylesheets
A large block-based theme can send hundreds of rules to a page that uses only a fraction of its components. WordPress’s block-stylesheet approach can load a block’s CSS only when that block is present and can inline it in the front-end head.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Split substantial block rules from global rules
Keep reset, typography tokens, layout primitives and other genuinely global rules in the main stylesheet. Move substantial component rules into per-block files, such as a stylesheet for a custom card block or a complex query-loop variation. This improves payload control and makes ownership clearer during maintenance.
Verify conditional loading
View the source or network panel for a page containing no gallery, form or custom card blocks. Their styles should not be requested merely because the theme supports those blocks. Then open a page that uses each block and confirm its stylesheet loads, its editor counterpart is available and no layout shift appears when the rules arrive.
Conditional loading is not a substitute for removing dead selectors. Delete obsolete variations, compress production CSS and check that critical above-the-fold styles are not stranded in a file that loads too late.
6. Use the Site Editor for reusable structure
Block themes expose templates and template parts in the Site Editor. Put site-wide structure there: headers, footers, archive layouts, single-post templates and reusable sections. This lets a designer change the composition without editing every page independently.
Apply a block change consistently
As of WordPress 6.2, a change made to an individual block can be applied to all blocks of the same type. Use that option when the change is truly global, such as a standard button radius or heading treatment. For a one-page experiment, keep the change local so it does not unexpectedly alter client content elsewhere.
Separate structure from content
Template parts should contain the repeatable shell; page content should supply the unique message. If a client needs a different announcement bar on one landing page, create a deliberate variant instead of quietly changing the global header. Name template parts so a future editor can identify their scope without opening every template.
7. Keep one-off CSS at the edge
A site-wide custom CSS editor has been part of the Styles interface since WordPress 6.2, and the feature requires a block theme and WordPress 5.9 or newer. It is useful, but it should not become the primary design system.
Put durable decisions in the right layer
- Use
theme.jsonfor tokens, presets, element states, layout settings and responsive values. - Use block styles or block-specific stylesheets for reusable component variations.
- Use template and template-part controls for structural composition.
- Reserve custom CSS for a genuine exception, a temporary experiment or an integration constraint that cannot be represented above.
When custom CSS is unavoidable, add a comment explaining the component, scope and reason. Avoid selectors that depend on editor-generated markup or deeply nested class chains; those are expensive to repair after a WordPress update.
8. Compare theme approaches before choosing one
| Decision axis | Classic theme | Block theme | Custom block system |
|---|---|---|---|
| Where global styles are authored | Customizer, PHP theme support and CSS; theme.json can supplement newer themes. |
Primarily theme.json and the Styles interface. |
theme.json plus code-owned block attributes and styles. |
| Template editing | Templates generally remain code-controlled. | Templates and template parts are editable in the Site Editor. | Depends on which blocks and templates the system exposes. |
| Responsive values | Usually CSS media queries, with explicit support for responsive embeds and other tools. | Responsive style settings can be represented in theme.json and block controls. |
Block attributes, theme.json and component CSS must be kept in sync. |
| Editor synchronization | Requires editor-style support and a maintained editor stylesheet. | Shared theme settings provide the strongest path to parity. | Requires editor and front-end assets for every custom block. |
| CSS loading strategy | Main stylesheet is common; conditional block files require deliberate implementation. | Block stylesheets can limit CSS to blocks in use. | Per-block assets offer control but increase build and testing work. |
| Client handoff burden | Clients may need training for code-controlled templates and Customizer settings. | Visual editing is easier, but only if exposed controls match the CSS. | Most controlled for a design system, with the highest maintenance responsibility. |
Choose the approach that matches the client’s editing needs and your team’s ability to maintain editor/front-end parity. A block theme is not automatically better if its available controls produce layouts the CSS cannot support.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.9. Run an accessibility-focused design review
WordPress provides an accessibility preference in the editor, but the preference does not perform an audit for you. Turn it on while reviewing and inspect the actual content and components.
Check the visual fundamentals
- Text and interactive controls have sufficient contrast in every color scheme.
- Keyboard focus is visible against light, dark and image backgrounds.
- Headings follow a meaningful hierarchy rather than being chosen only for size.
- Body text remains readable after zooming and at narrow widths.
- Images have useful alternative text, and decorative images are treated as decorative.
Check behavior and content order
- Tab through menus, dialogs, forms, links and custom blocks without a keyboard trap.
- Confirm stacked mobile content follows the intended reading order.
- Ensure embedded media has controls, captions or transcripts where appropriate.
- Do not communicate meaning by color alone; include text, icons with labels or another cue.
The exact audit depends on the site’s content and components. Record exceptions as concrete tickets, naming the template, block and viewport rather than writing a general “accessibility pass needed” note.
10. Use a practical pre-handoff checklist
- Lock the system: confirm colors, type scale, spacing presets, layout widths and element states in
theme.json. - Audit controls: remove editor options that the CSS does not support; verify wide, full-width, spacing, link-color and embed behavior.
- Compare canvases: open representative pages in the editor and front end, checking line wraps, widths, image crops, buttons and forms.
- Test three states: review base, tablet and mobile values at the theme’s documented or customized viewport widths.
- Inspect payloads: confirm unused block styles are not loaded and that blocks in use receive their required CSS.
- Review templates: test header, footer, archives, single content, 404 and any template parts a client can edit.
- Run keyboard checks: verify focus visibility, tab order, skip links, menus, dialogs and form errors.
- Check content resilience: test long headings, translated labels, missing images, empty query results and unusually long button text.
- Document safe editing: tell the client which controls are global, which changes affect every instance and where an exception belongs.
- Record known limits: list integrations or third-party embeds that need special CSS or future review.
11. Troubleshoot the failures designers see most
The editor looks narrower than the live page
Check the editor stylesheet, the main and wide content widths and whether a theme or plugin adds an overriding max-width. Compare the same block’s computed styles in both contexts instead of adjusting padding by eye.
Free tools Windows power users keep installed
One-click scans. No signup required.
A full-width block creates horizontal scrolling
Inspect parent containers for fixed widths, horizontal padding and overflow rules. Test the block inside groups and columns, then verify the full-width calculation at the narrowest supported viewport.
Mobile styling appears to be ignored
Confirm the responsive key is valid, the theme’s viewport configuration matches the value you are testing and a mobile value was set explicitly. A tablet override does not automatically become the mobile value.
A client changed one button and every button changed
Determine whether the change was applied to all blocks of that type, a synced pattern, a block style or a global element rule. Keep one-off experiments local and use a named style for intentional reusable variants.
Pages load CSS for blocks they do not contain
Move heavy component rules into block-specific stylesheets and verify the enqueue condition. Keep only truly global declarations in the main file, then retest pages with different block combinations.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesQuick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
