Previously #5360

I'd like to define some areas of work around theme styling that go beyond WordPress 5.0. During the last 37 releases we have seen how the existing pieces interact together, so we should have a clearer idea of what has been working and what needs another look. While some of these tools and functionalities are already in place or underway, their full deployment will continue into the next phases of the project.

That means not everything has to be resolved now but we should make sure that the path forwards is one that can reach a fruitful destination one step at a time.

Strategy

• Editor Styles. Gutenberg has allowed customizing how blocks look in the editor since the very beginning, but the mechanisms for doing so face some of the inherent problems of the cascade when we are working with a component mindset; on top of the structural differences between back-end and front-end. We need a better longer term solution and a smooth developer experience. The exploration in Styles: add Editor Styles support #9008 is looking very promising in reducing the amount of playing-the-CSS-specificity-game themes would have to do otherwise, while also avoiding coupling with any specific DOM structure. It also paves the way for an even more robust solution in the future once Shadow DOM is ubiquitous enough that we can rely on it for style encapsulation.

• Block Style Variations. This Is an API that evolved relatively late in the process as a way to offer simple yet expressive customization mechanisms (Create unified UI for block variants #783, Block API: Add block styles variations API #7362). It allows registering new styles for blocks that are entirely based on class names. This needs to be expanded from a developer perspective (in JS it exists as wp.blocks.registerBlockStyle( 'core/quote', 'fancy-quote' );) so that block styles can be registered for any existing block from the server. Might be interesting to see if it can be tied closer with the above point about editor styles sot hat they can show in "block previews", etc. See further tasks in Continuation of Block Style Variations #7551:

// Server
add_block_style( $block_name, array(
    'class' => 'my-class',
    'title' => __( 'My Style' ),
) );

// for both editor and front-end
.{block-name}.is-my-class-style {
    color: blue;
}

• Theme Support. There are a few aspects of customization that have been added as add_theme_support() calls (colors, fonts, wide alignments). There's also a discussion point about consolidating these declarations at Consolidate add_theme_support() features into a single array #8732. However, theme support is problematic on a few fronts. It's unaware of context, which means supporting something like "wide" alignments doesn't take into account that "wide" might be contextual to the block nesting level you are operating at. Consider a case where a theme has two templates, a single column one and one with a sidebar. Whether adding content to the main column should have access to "wide" alignments depends on which template is being used. More importantly, with the addition of blocks like Columns or Section, it becomes evident that these alignments only make sense, as so far specified, when used at the root of the block list. As soon as blocks are added within multiple layers of nesting, the wide alignments cannot reflect the presentational intention anymore. This means that such a set of properties ought to be more flexible, depending largely on the context of the current InnerBlocks. Here are a few thoughts on how this could be developed:
  ➖ Absorbing add theme support as InnerBlock properties.
  ➖ Allowing themes to more flexibly define these properties through templates. See also Proposal for Block Templates #3588.

• Colors, Fonts, & Configuration. The aspect that mostly makes sense of add_theme_support is one of configuration — a theme can specify which colors should cascade down to blocks, what base font sizes should be used, etc. Yet again, this is a bit of a heavy handed approach, because it's conceivable that the "colors" array should be contextual to InnerBlocks too. Imagine a theme with a dark sidebar and a white main column: the colors available to use when a block is in the context of the sidebar might need to be different than those offered when blocks are being used on the main content. Likewise, which colors are shown to the user might also be block contextual. My impression is that almost everything that we generally place as add_theme_support might actually be better expressed as properties of blocks / layouts / templates.
  ➖ Related action item in Define preset color array and naming convention for uniform colors across themes #7553.
  ➖ Colors documentation in Documentation: Colors: Add withColors readme with a sample. #7906.
  ➖ Alignments in Fix: Align: Only add data-align for wide/full aligns if editor/theme supports them #9481.

• Widths & Responsiveness. WordPress has historically relied on a global variable called $content_width to allow themes to express their intended content width. This variable has proven to be awkward to use since the early days of responsive web design given its static nature. It's common to see themes write a mixture of checks around this variable to try to contextualize it. This is an area where the first point about editor styles is going to help tremendously, because now the theme can express container widths just through CSS as if it were the theme itself. The ongoing work around responsive images also ties into this.

Action Plan

Apart from introducing the changes in #9008 and refining #8732, I'd love to open the strategy outlined above for general discussion. What do you think? Any other ideas?