Block-based Meeting Notes – Oct 7, 2020 – DocsWP

Location: Make Slack #themereview

Facilitator: @kjellr

Gutenberg + Themes Updates

An overview of FSE + block-based theming for 5.6 release was shared: https://make.wordpress.org/themes/2020/10/07/block-based-themes-and-wordpress-5-6/
Here’s a post about what’s new to Global Styles / theme.json: https://make.wordpress.org/themes/2020/10/01/gutenberg-9-1-new-json-structure-for-fse-theme-json-files/
Try this web-based GUI to generate a theme.json: https://gutenberg-theme.xyz
Twenty Twenty-One theme development is going strong! The block-based version is set to begin after Beta 1 (Oct 20).

Discussion: which design tools should be enabled by default?

Gutenberg is building in a suite of design tools: https://github.com/WordPress/gutenberg/issues/20331. Some of these have already been implemented, and are available as theme options:

For these sorts of options, and upcoming ones like font weight, family, and expanded spacing controls, it would be helpful to get thoughts from theme authors about what should be enabled by default, versus having them be opt-in.

Full discussion begins here, but here are some highlights:

@aristath shared:

For FSE themes they should all be opt-out IMO… enabled by default and if defined as false in the theme.json file then disabled.
Note: I’m referring to FSE themes, not “classic” themes

Several folks agreed with this view, but @greenshady raised an important counterpoint:

Design features that may interfere with theme styles need to be opt-in by default… When it comes to theme-supported features in general, I tend to lean toward an opt-in approach. That gives themers the ability to explicitly make a choice.

Some of the discussion centered around whether add_theme_support should be used to control editor features:

I’m OK with going opt-out, but I don’t think we should misuse the theme supports system if it’s not genuinely meant to be a theme-supported feature.

@kjellr summarized the discussion saying:

If a theme has theme.json, it seems ok to have these be opt-out.
Otherwise, if the feature is expected to “just work” with themes without breaking something, it’s probably ok to enable it by default. Otherwise, they should be opt-in.
If these are “editor” features, and not something the theme needs to explicitly build in support for, then it may be confusing to use add_theme_support() for them.
If users move between block-based themes and non-block-based themes, it will likely be confusing for seemingly unrelated features to turn on and off.

A follow on discussion ensued about how to make the distinction between block-themes and classic themes, in the themes directory and wp-admin.

@kjellr opened a meta ticket that could house the discussion between themes, meta, and design teams: https://meta.trac.wordpress.org/ticket/5465

#meeting-notes