Block-based Meeting Notes – Oct 7, 2020

Location: Make SlackSlack Slack is a Collaborative Group Chat Platform The WordPress community has its own Slack Channel at #themereview

Facilitator: @kjellr

GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. + Themes Updates

  • An overview of FSE + block-based theming for 5.6 release was shared:
  • Here’s a post about what’s new to Global Styles / theme.json:
  • Try this web-based GUI to generate a theme.json 
  • Twenty Twenty-One theme development is going strong! The blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.-based version is set to begin after BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 (Oct 20).

Discussion: which design tools should be enabled by default?

Gutenberg is building in a suite of design tools: 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 FSEFSE Short for Full Site Editing, a project for the Gutenberg plugin and the editor where a full page layout is created using only blocks. 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.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML., 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: