Block-based Theme Meeting Notes 20 May, 2020

This post summarizes the latest biweekly 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 Themes meeting, held in the #themereview SlackSlack Slack is a Collaborative Group Chat Platform The WordPress community has its own Slack Channel at channel on Wednesday, 20 May, 2020, 16:00 UTC.
You can find the agenda here. Facilitator: @jffng


A new weekly digest post will be available to help theme creators keep up-to-date on developments in changes in the editor and full site editing related to theme creation. The intent is to make it easier for theme creators to follow and participate in decision making that directly impacts their work. The first post went up last week. Please leave comments below if you would like to see additional content included in this weekly post

There is also an open call for Full Site Editing testing. Please sign up using the form on the post by 22 May.

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. Roundup

Issue 22368  — Allows navigating the site editor by switching between the site’s pages. This provides the ability to see the context of your content (instead of placeholder) while editing the actual template it uses. It makes use of the post and query block and can lead to a more intuitive approach to viewing and editing site templates.

Issue 22296  — It’s a worthwhile read to understand previous attempts (e.g. PR 22317) to style blocks from a theme, and to understand what’s coming next. The takeaway for us is that very soon, themes will have a new mechanism to style blocks and block patterns.

Format of theme config file — The format is a work-in-progress and will change. Follow these PRs:

Meeting Topic

How can the experience of styling blocks be improved? What is challenging about styling blocks today?

@aristath — Why are Global Styles not using css-variables. Then if we wanted to override globals for a specific block, it would simply be a matter of defining the vars inline in that block. It would also have the benefit of a properly cascading mechanism, and scoped styles made really simple. The “managed css” solution proposed seems way more complex.

@jffng I believe the “managed CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site.” proposal is agnostic to the use of CSS variables. But I think part of the problem with using CSS variables on a per-block basis results in a variable set that is unruly and difficult to manage when you get into situations where you need to target nested content.

@kjellr Well, they do get translated to CSS variables. But in terms of why, global styles is currently exploring 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. for defining those variables instead of just a CSS file. I believe that’s because some of the possible block settings that would be included as part of global styles don’t map directly to CSS variables. For instance, the “features” or “presets” noted here. So for instance, having a drop cap turned on or not. That wouldn’t make sense as a CSS variable, but we may want to specify it in our theme.

@kjellr I find that most of the struggle for me is related to alignments and layout. On the front end, we’re building in those styles from a blank slate, whereas in the editor we build on top of a base structure for wide/full/etc. I’d love to have a solution that either shares that base structure with the front end (optionally) or clears out the editor to also be a blank slate as well.

@aristath I’d have to say the specificity of coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. styles, the use of px values for font-sizes, and hardcoded colors. It requires themes to re-invent the wheel every time and rewrite everything from scratch in order to accommodate a darker background-color or larger font-size for example.

@kjellr I think this is related to my note about the blank slate too — the editor uses those px values because the cascading of em sizes is really difficult to maintain in the editor at the moment. Hopefully, global styles can unlock that issue.

@aristath If we were using em or rem for core styles, themes would be able to even do responsive font-sizes a lot easier. All it would take is defining something like :root{font-size:calc(14px + 0.4vw);}  and presto, we’d have font-sizes that adapt to the screen sizes. Now, we have to rewrite all core styles in our themes instead.

  • Issue 11671 — a path toward responsive, non-px font sizes
  • @karmatosed Changing out base measure is also something to be done throughout, so if doing, it needs co-ordination. It’s worth noting global styles shouldn’t dictate the baseline we use, it inherits it. So whatever we choose, it should adapt to.
  • @aristath For the present, individual PRs per block will be submitted changing to either em or rem from px because one overall PR would impact too many places.

Open Floor

Additional proposed community resources for Gutenberg-enabled Themes — could help theme creators during the transition.

  • Transition Guide from traditional to block-ready themes:

A list of what the differences are between old style and Gutenberg.

  • Video round-table discussions/presentations:

Bi-weekly or monthly theme developers round table held via video where there is a short presentation. It could alternate between theme developers and the Gutenberg team, people could present their work, problems, etc and ask questions and give feedback.

WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. EU Contributor DayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of There are many teams that people can participate in, each with a different focus.

Tuesday June 2 @ 17:00 UTC For the theme team, most of the afternoon will focus on 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. and Block-based Themes.