Now that WordPress 5.3 Beta 1 is open for testing and with the official release slated for November 12, it’s time for theme authors to begin making sure their themes are ready for several changes.

Most work will revolve around the block editor. WordPress 5.3 will include versions 5.4 – 6.5 of the Gutenberg plugin, a total of 12 releases. This makes for a lot of ground to cover. The next release includes breaking changes.

For themes without custom block styles, little should change. However, theme authors who have been building custom block designs will likely have some work to do if they haven’t kept up with the changes in the Gutenberg plugin over the past several months.

Block Style Variations API Introduced

WordPress 5.3 introduces new server-side block style functions. This means that theme authors who prefer PHP can now register custom block style variations without writing JavaScript code.

The block styles feature allows theme authors to register custom styles for individual blocks. Then, they must apply custom CSS to these styles in the editor and the front end.

The new functions are basic one-to-one matches to their JavaScript counterparts. Block styles still need to be registered on a per-block basis. Support for registering single styles to multiple blocks at once hasn’t landed in core.

New Block HTML Creates Breaking Changes

Despite WordPress’ commitment to backward compatibility over the years, the Gutenberg team hasn’t maintained that approach with blocks. Block HTML output in the editor and the front end has changed for some blocks. These changes will break custom theme styles in many cases.

The following blocks have potential breaking changes for themes:

  • Group: A new inner container element was added to the markup.
  • Table: A wrapper element was added and the block class moved to the wrapper.
  • Gallery: Like the table block, it received the same wrapper element treatment. Galleries also support a caption for the entire gallery block.

In my tests, the gallery block had the most obvious breaking changes. Depending on how it is styled, users could be looking at a single column of images instead of their selected number. The core development blog has a complete overview of the HTML changes along with code examples for addressing issues.

It’d be interesting to see if the Gutenberg team makes similar HTML changes with other blocks in the future. Such changes make it tough for theme authors to maintain support between versions of WordPress and versions of the Gutenberg plugin. It also bloats CSS code when attempting to maintain compatibility. Adding an extra element doesn’t typically break things. However, moving an element’s class to another element is a dumpster fire waiting to happen. If these types of changes continue to happen, it could turn some theme authors away from supporting the block editor at a time when core needs to be encouraging more authors to design around it.

New Block Classes Added

Several new CSS classes are making their way into 5.3. For themes that remove core block styles on the front end, they need to add support for the classes to their theme’s stylesheet.

WordPress is doing away with inline styles for left, right, and center text alignment. This is a welcome change because it moves CSS to its appropriate place, which is in a stylesheet. Theme authors need to make sure they support these new classes for the following blocks.

  • Heading
  • Paragraph
  • Quote
  • Verse

The columns block no longer supports column-specific class names. Version 5.3 supports custom column widths, which are handled with inline styles. It’s unlikely this will break most themes, but it’s worth testing.

The separator block now supports custom colors. It is given both the text and background color class names on the front end. This allows theme authors to utilize the styling method they prefer. Ideally, a border color class would exist, but the block editor does not yet support selecting a custom border color.

Quick developer tip: if your theme uses a border color for the separator block, use currentColor to handle custom colors.