This is an overview of theme related considerations for Gutenberg as gathered after several months of testing and feedback.

WordPress Block Styles vs Theme Styles

During the evolution of Gutenberg we have introduced several blocks with somewhat opinionated styles (quote, pullquote, separator, etc). We have seen how some themes really don't want these — they might conflict with their base styles — while other themes really want to build on top of them (particularly new themes). We have opted to disable the opinionated styles for some of the blocks that map to HTML primitives, like blockquote, because almost every theme defines those for themselves and would be tough to accommodate all conflicts. This has meant we have prevented new themes from reusing the styles that appear on the editor for all these elements. We are seeing some vanilla themes that do want these styles and would rather just customize on top of them.

This means we are looking at a split between themes that don't want any visual style (not considering structural ones here, like columns, galleries, etc) coming from core blocks and themes that do want these styles as their base. It seems we should figure out a way to accommodate both needs.

Anatomy of a Block's Style

Currently we define block styles in two stylesheets: "style" and "edit". The main problem is that if we want to supply visual styles to some themes, we cannot split them from structural styles that should come for all themes easily. So I am proposing we look at establishing three separations for block styles:

• style.scss are the shared structural styles.
• edit.scss are the editor specific styles.
• theme.scss are opinionated visual styles.

With these separations we can always include the base styles for all themes, but make theme styles optional. A theme would have to do something like add_theme_support( 'wp_block_styles ' ) to load these if they want to. (Bonus points if through the structure of theme.scss we could find easier ways for a theme to supply their own styles to the editor. Imagine having a blocks folder under your theme where you can add a css/scss file per block which is used to concatenate into the editor, but I digress.) During build, we should include the visual styles in a separate stylesheet.

Previous: #2905

Classes vs Inline Styles

A similar split exists between basic and advanced customization options. We have a couple blocks that have a fair degree of styling possibilities around colors and font sizes. We allow themes to disable custom colors and to register their own already. We are also looking at providing an array of font sizes that would map to classes is-small-text, is-regular-text, is-large-text, etc, so themes can dynamically set these values. The ability to set custom values is still welcomed for various contexts, so it's looking like the best separation is:

• Basic: Classes for the predefined sets (colors and fonts).
• Advanced: Inline for custom values.

For basic we avoid all saved inline styles, and advanced is something that could be disabled by a theme or plugin if necessary.

Colors

Would be registered assigning a name to each color value. The name would be used to construct a .has-color-{name} class as well as show a tooltip for accessibility.

$colors = array(
	'Blue' => '#00B1D4',
	'Violet' => '#934ED4'
);

Applying one of these colors won't generate any inline style. See #5273

Fonts

In the case of fonts, there'll be a set of predefined sizes that would map to classes. The set would be provided as an array of values which would be used to generate the value in the editor, while the only thing saved would be the corresponding class (i.e is-small-text, is-regular-text, is-large-text, is-larger-text).

The UI would be close to this proposal:

See #5269

This issue will be updated with further details as they come by.