This post summarizes the latest bi-weekly Block-Based Theme meeting, held in the #themereview Slack, on Wednesday, February 5, 2020, 16:00 UTC. These meetings coordinate collaboration in the development evolution of the Gutenberg project as related to development of Block-Based Themes geared to support Full Site Editing. Moderated by @kjellr.

Important Project Links

• Global Styles
• Full Site Editing Blocks
• Semantic Tags

Global Styles Update

@kjellr Some recent full-site editing work affects themes. The first one is this PR 20047 by @nosolosw — Consolidate overall Global Styles mechanics in the server. This PR is a foundational step for the Global Styles work. It lets themes start specifying global values in  experimental-theme.json file. There are a couple example PRs in the `theme-experiments` repository to show how that would work. Technically, what this all does is convert the JSON into CSS variables, which will be able to change on the fly from in the Global Styles interface. It’s still very early, but it’s a good time to take a look and discuss in GitHub PR 17  and  PR 22

Speaking of the Global Styles interface I’d like to highlight PR 20061 by @itsjonq which introduces an initial interface for Global Styles in the beta site editor. Everything lives within a single sidebar for now. Like the Gutenberg PR noted above, this is an early foundational piece. It’s a good starting point for later work.

New Full-Site Editing Blocks

@kjellr These will all come in handy for block-based themes. Many of these have been merged in already, but I wanted to list them all so that we’re all up to date. These are already available for use in block-based themes.

Some of the new blocks that have been merged in recently include:

• Post Title
• Post Content
• Post Excerpt
• Post Author
• Post Date
• Post comments form
• Post comments count
• Post comments
• Featured Image

The post tags one is still in the works. Here’s a good place to follow along.

Semantic Tags in Gutenberg Blocks

@kjellr  There’s also an effort going on to figure out how Gutenberg blocks should render semantic tags like <header>, <main>, <section>, <aside>, and <footer>. This is a great structural question allowing blocks to render semantic tags for full-site editing.  Follow along here at Issues 20200. There’s already a PR as well.

Query Block

@kjellr  A major new block that’s being worked on is the Query block – PR 20106. This will be the driving force behind archive pages or really anything with a list of posts on it. The query block is the equivalent of the loop.

Theme Demo: Go

This is a time for us all to learn a bit about how others are building block-friendly themes today. @richtabor is going to tell us a bit about how and why the Go theme uses CSS variables, and how that made it easier to style blocks.

@richtabor I’m here to share about the Go Theme from my team at GoDaddy: why we made it, what’s now possible with Go (and potentially core themes in the future), and how it works. We wanted to develop an experimental design system where folks may easily adapt Go by modifying, or even add a whole new style. Pretty much an initial concept of what Global Styles is aiming for. This means that with WordPress, one theme (Go), and one plugin (CoBlocks – though you don’t have to use a block plugin) – you can make all the themes here. Some of my favorite website demos are:

• Barista
• Everett
• Chai

Now onto how the design styles work. Currently we’re leveraging the Customizer for much of the heavy lifting of the user-facing design choices – though we’ll migrate the theme to global styles as soon as it’s stable. We provide five different design styles, which can be swapped out at any time. These design styles are built using CSS variables (custom properties) and are defined within the theme – although are easily manipulated anywhere (as the nature of CSS variables). And we do have fallbacks in place, so not every variable needs defining within a design style – making things simple to manipulate

Here’s an example of what the Modern design style looks like in code:

:root {

    /* Content width */
    --go--max-width: 38rem;
    --go--max-width--alignwide: 90rem;

What’s particularly great about using CSS variables is that these style declarations are not only easily manipulated/overwritten when necessary but they’re easy enough to provide within the block editor, making one-to-one visual editing MUCH simpler to implement. Here’s a look to the screen shot in Slack into the editor of the same website I previewed in the Customizer above. Pretty much one-to-one visually

Global Styles will be defined a bit differently, although in theory — they should perform similarly to what we have in Go — a set of declarations that define a site’s design that may be overwritten by the end user. It’s not block-based yet, but an experiment of what global styles could be capable of. We’ll port over to FSE and global styles as soon as it’s stable.

If we extend the idea of Global Styles a bit more, like the following experiment, perhaps WordPress makes way for something like this in core

In this video, we’re declaring a site’s spacing/rhythm using a singular control. Note that the control/UX in the experiment above is just to show how setting spacing could work in theory, not how we’ll implement it at all.

So that’s what we’ve been working on, experimenting on a design style system that’s portable, easily manageable, but ultimately empowers folks to publish beautiful websites that looks and feels right to them.

Transitioning Legacy Themes

@aristath discussed ideas for transitioning older themes to block-based themes. He published a great post. While experimenting with block-based themes it’s becoming more and more clear that there is no easy way for themes to be “updated” to take advantage of FSE. It’s either a new theme or nothing. And though that’s OK looking 5 years in the future, it’s not OK for businesses and authors that have spent countless hours building solid products and a user base of thousands. There are 2 ways to look at this situation:

• It is an opportunity to start fresh. No baggage, no nothing. It’s a new beginning for everyone – which will benefit new authors.
• No way forward for existing themes – which is bad for existing authors.

That’s not to say that existing themes MUST convert to block-based. They will surely continue to work the way they are for many years. But some themes will definitely want to. And we want to avoid issues of the past where every theme tries to reinvent the wheel and 90% of them are doing it wrong. That’s why we’re suggesting in that post that a library be built, allowing themes that wish to upgrade to do it in a consistent fashion, using a method that we properly test and implement.

We’d love your feedback on the post so we can figure out how to move forward. It won’t be an easy task, but we feel a lot of existing theme authors will benefit from something like that. So far there is no code to look at, just ideas and experiments, so feel free to share your thoughts 

Q & A

CSS vars are becoming the norm, so we should encourage them. But so far I don’t think we dropped IE11 support. What about that?

@dingo_d

@richtabor IE 11 support is tricky. We do have fallbacks in place – also utilizing polyfills – though the end result is not the best.

@johnstonphilip There was a lot of discussion on polyfills for IE 11 in this GitHub Issue 19611 My understanding of the takeaway there is that ie11 should work, but it doesn’t have to be pretty

@kjellr There’s also some relevant discussion that happened in the CSS Meeting in #core-css last week.

@aristath Saying a theme “supports” IE11 is not the same as saying that IE11 will display things the same way a less-than-10-year-old browser will display them. The way most of us treat IE is that things need to function properly, users must be able to use the site and interact with it. But if the color scheme for example is not the same or the paddings are different because css-vars are not supported then I’m fine with that. Most users are.

I was building my first block based theme today. The site title block is not fully developed yet? I don’t understand either what will happen with translations.

@acalfieri

@kjellr The site title block should be available as of today PR 17207

Are there any plans for dropping IE11 support in the near future?

@acosmin

@dingo_d There was a discussion in meta regarding dropping IE support, and we cannot do that completely (not for a number of years at least) because some companies are pretty much tied down to use IE (corporate mostly).

@kjellr  In general, it sounds like the IE11 question doesn’t have an answer yet, but folks are all in agreement that some sort of fallback is required.

Reading through the migration proposal from @aristath this still has theme authors creating site templates in Gutenberg and then copy/paste the resulting block code. What is the point in the migration/script if that is the exact same process for creating a Block Based theme? Before running the migration, it seems a new theme has been created, no? The “migration” simply takes into account existing user settings. Simple example: If on my current theme I have defined that the background-color of the copyright area is red, then I want on the new version my background-color to remain red.

@BMO

@aristath The “migration” simply takes into account existing user settings. Simple example: If on my current theme I have defined that the background-color of the copyright area is red, then I want on the new version my background-color to remain red.

What’s the benefit of using an API approach shown by @aristath instead of just adding a header.html template in the old theme?

@kjellr 

@aristath  Your theme will still have a header.html. But in your header.html you’re defining the initial state of the header, correct? So basically what users see when they first install a theme, with its default settings. But on my site I don’t use the defaults… I went in the customizer and changed colors, font-sizes or whatever other settings my theme has. When I update the theme on my site, it should not reset everything. That’s where the “migration” part comes in. It will help users of existing themes not lose their settings when/if they update a theme.

@kjellr Ah ok, I think that makes sense. I think that’s something global styles would solve though, right? Since you’d specify those new colors/font sizes/etc via global styles too? Or I guess with your approach, you could not have to do that?

@aristath it depends…. If I have a setting on my theme “Top-header/Side-Header”, then the structure of the blocks would change. A migration could take care of that if the theme-author writes if this setting is set to side-header, then inject this template

@allancole  What was the process used in the Go theme to determine which style rules would be CSS-variable-ized? And related to that, what happens when replacing the available variables isn’t enough to achieve a certain design? Can the variables be extended or do you resort back to normal CSS?

@allancole 

@richtabor  Customizer settings will likely have to be mapped into styles manually (other than core defined settings) Most design-level choices are variables, though fallbacks are available on most variables so that each design styles doesn’t have to have a lot of variables designed – only what they need.

Have there any conversations around having a block based theme’s .html files listed in `Admin -> Appearance -> Templates`? This would make it easier for a user to open a copy/clone of the template, make their changes, then save as a new template override. Right now, a user would have to know the name of the .html file, create a new template with the same slug, then start from scratch. I also know that the Beta Site Editor is solving for parts of this, but is there value in seeing all of the templates listed out?

@BMO 

@kjellr  I could be wrong, but I think that’s the goal. I’m pretty sure I saw a PR about that and for Template Parts. I think discussion is here Issues 20252 I also checked with @epiqueras, who noted that the Appearance sections are just for development. Eventually this will all be available contextually within the full-site editing UI. I believe “Appearance” > “Templates” is just a temporary home.

We covered a lot of new template blocks but what about navigation? It is in the plugin (experimental) but using it is still not a good user experience. Is this planned for later than 5.4 release?

@dingo_d

@kjellr  There is a lot of iteration planned for that block which is part of the reason it was left out of the upcoming release. See the full post here. 

The next meeting is Wednesday, March 4, 2020, 16:00 UTC.