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.

Overview

This meeting is the first of its kind and serves to introduce topics around block-based theme engineering to the wider community. It was moderated by @kjellr, @jffng presented an overview on Block-Based Themes and Full Site Editing and @karmatosed presented an overview on Global Styles. There was a lengthy Question and Answer period to discuss issues and concerns from theme authors and reviewers.

@kjellr As most of you probably know, Gutenberg is in the process of expanding beyond the editor. As we’ve already seen, Gutenberg allows for a great deal of user-customization inside of post & page content. It allows any user to create custom layouts all by themselves, and style adjustments too. These will all usually be retained even after a user switches themes. With full-site editing on the horizon, Gutenberg is aiming to do something similar with the rest of the site. By turning elements like the header and footer into block areas, users will have the flexibility to place any sort of content wherever they want. It allows for a lot of creativity! They’ll theoretically be able to click and edit their header in place, or change their sites entire color scheme without needing to jump into an entirely separate interface. Themes have to figure out the role they play in this future, and that’s why we’re here today. This meeting should be a place for us to sort out that role together by learning, discussing, and experimenting.

What is a Block-Based Theme?

At the moment, it’s a theme made up of html templates, which are composed of blocks.

@jffng provided an overview of Block-Based Themes and Full Site Editing:

• The early draft spec for block-based themes is in the Handbook with an overview which at the moment is a theme made up of html templates, which are composed of blocks.
• You’ll notice two “new” directories in that folder structure: block templates and block template parts. Block templates function similar to how existing php templates we’re used to in themes.
• Block template parts define an area of the site that would be reused across multiple block templates.
• The WordPress theme-experiments repo on GitHub contains a few examples of this implementation. These examples are not intended for production. They are experiments to try and break how this works, ultimately identifying how block theme development should work and could be improved.
• To try out these demos, install the latest version of the Gutenberg plugin, and enable the “Full Site Editing” option under the plugin’s “Experiments” section.
• A video demo of Full Site Editing is available by @epiqueras on Gutenberg Times.
• A good place to see the work-in-progress (both design and dev) related to full-site editing is on GitHub.
• New blocks are being added to make full-site editing possible on GitHub.
• This is all very early so your feedback, testing, and iteration is so important. In general, a good way to provide feedback is to open an issue in Gutenberg. That will provide necessary visibility so theme authors voices are heard.

What are Global Styles?

@karmatosed shared an overview and some tools that are going to be available as part of Global Styles and also gives some links to start following as this is explored. This is all still in very early stages (imagine we’re still at the ‘what goes in cake’ stage of baking) and as you’ll see from some tickets lots of early sketch and map sharing.

What are global styles? In short, it’s style you can apply across your site right there in the browser. Pretty neat! Think of it as a kit full of component tools you can activate and take advantage of. Tried, tested and ready to go. It’s your decorating kit to get your site space just the way you want it.

In the kit comes:

• Colours: text, background and primary (themes can set defaults)
• Typography: change font size, scale (including line height) and alignment.

However, is that enough? This is currently a big question being questioned. There needs to be exploration on what are common things needed and what needs to be available.

Currently on issues, I will share there is some exploration as to what really we need as baselines to create those layouts users have dreamed of.

These are tools available in the editor, so addressing what is needed or not is key, over allowing everything and creating a complicated experience. A personal point I’m thinking about here is how when I had a crowded art box I could never find that ‘one pencil’ I wanted, we want to avoid that.

There is a project board you can follow along as this work happens over in GitHub.

Open Floor Questions

Is it possible we can discuss a sort of middle ground that doesn’t jump us completely over into block-based themes? I think a lot of theme authors were excited about the idea of defining custom block areas within the scope of their themes, sort of like how sidebars work. Right now, there’s certainly some valid concern that by making the entire theme based on blocks, which can be moved around and changed, that it could take away some of the artistry of designing themes. This calls into question whether there is a real need for themes in the future. Assuming everything can be customized by the end-user, themes seem to be little more than styles for individual blocks. While that can be a good thing for some people, not all overall designs can be broken down to the block level.

@greenshady

@kjellr (responded) not all overall designs can be broken down to the block level: I think this is the sort of thing that is best answered by some experimentation. The best plan of action at the moment is to try making our best theme-design wishes into blocks, and see where they fall apart and when those holes present themselves, let the Gutenberg team know.

@allancole I’ve been thinking about this too @greenshady but the craft and artistry that themers are used to doesn’t go away with Block-Based Themes in my view. Instead that craft appears in how we design, organize and layout blocks on a given page or set of templates. You end up using Gutenberg itself to express that same creativity, rather than doing it with PHP and JS and theme options where it’s harder for users to change and modify.

@karmatosed One thing I wanted to answer about artistry. A frame of thinking about it for me is art direction. In many respects a lot of this is bringing more artistry, allowing a tone to be set. Think of it as creating a theme that has a style boundary.

Are any of the experimental block themes magazine-style themes?

@Carike

@kjellr not yet, but there are only a few of them. The main thing holding back a magazine-style theme so far is a posts/query block (which is in the works!)

Global styles sound great. Are there plans on how to handle font-sizes on smaller devices/screens? Currently if you add a large font-size in the editor, it is added inline, thus it is nearly impossible to make it smaller using media queries, unless of course you add a special class for each use-case.

@ianbelanger

@itsjonq Are there plans on how to handle font-sizes on smaller devices/screens? The technology for Global Styles that we’re exploring is CSS Variables (if not that, than something that works very similarly.) This would make it possible to do media query targeted adjustments in CSS without a lot of forced overrides.

The issue brought up, that being inlined style values, makes it very difficult to customize after the fact, the CSS specificity is way too high. The variable system’s specificity is way lower, giving blocks/theme CSS more flexibility/control when it comes to adjustments.

Style conflicts (theme vs plugins) has existed in WP for a long time. Adding Gutenberg editor along with custom 3rd party blocks makes the problem worse. The reason is, there was never an underlying style system that connects all of them together. We’re hoping to help solve that with Global Styles. At least from a Gutenberg x Blocks x Theme x User Customization perspective.

Is there a core release target for either block-based themes or global styles at the moment?

@modernnerd

@karmatosed Global Styles likely will be this year but there is no release date set yet. There will be plenty of notice of these fun tools coming in to a release. So that information should be clear as time goes and they are worked on.

How far in the future do you think block based themes would be working in a normal installation?

@acalfieri

@kjellr the rough timeline at the moment is experimental through mid-year, with something basic in place by the end of the year.

How does theme switching work? HTML is preserved in content but what about styles? When the theme switches are the custom styles of the author lost? I am trying to understand the role of the existing theme author here, and how they differentiate their design philosophies from other authors.

@kevinhaig

@karmatosed The styles can be limited by providing solid defaults that’s a setting for someone to use. A good example is the colour palettes in paragraph block. A crucial bit is this has to make sense to the user on switch, nobody likes surprising things done by their theme or by their editor.

@kjellr There’s some discussion around hierarchy of styles happening in GitHub. Essentially, there are tiers of styles, and some are retained during switches.

Providing support for the users own templates may become difficult for theme authors… it is already difficult for users to explain the problem they are experiencing.

@poena

@kjellr That’s a great point. It would be great to come up with a way to make support/troubleshooting easier.

Global styles: Are they theme-specific, or site-specific? If site-specific, will/should themes be able to set the global style on activation so they can guarantee the theme matches the demo?

@modernnerd

@Carike Most users want to pick a picture and have their site look like that – with only small colour / font size / etc. adjustments that can be done by overriding the CSS.

@aristath Right now they are site-specific, and the theme can set the defaults. Right now the discussion is to set them using a json file, but that is not yet a decision set in stone.

@melchoyce That’s going to be the beauty of Gutenberg patterns, you activate a theme and it can actually look like the demo

It sounds like the scope of design will be narrowed for theme authors.

@kevinhaig

@karmatosed With the new space I get to set the tone of things, create the experience and unlock the power of blocks. I also get to set boundaries for how things could look and guide users with theme palettes.

@melchoyce I’m not personally concerned about this decreasing creativity — I think we’ll actually be able to be more creative because we won’t have to stress about “is this a widget, is it an option, etc.” For example, here’s an experimental theme @jffng, @allancole and I are working on now Portfolio: Nwaneri

@kjellr It depends on how you look at it. A large part of this is actually just changing the tools — giving theme authors a different place to define things they’re currently defining in many different ways. Themes will still provide those color/size combos by default.

@Carike I think this demo looks really cool. I just don’t think the average user is going to easily find a colour / size combo that is actually going to create a cohesive feel.

@karmatosed An early example of that is our a11y color check right now and theme palettes. What if a theme could offer a pairing of fonts or preset color combinations? There is also a future of plugins extending this to create full art direction.

Block templates: Is the plan still to allow users to override theme templates and template parts via the admin area? If so, doesn’t this mean theme developers can no longer assume their theme templates/parts will be used when their theme is activated? (Users could be overriding a named template in their old theme that the new theme also uses.)

@modernnerd

Will it be possible for theme authors to lock certain block templates / template parts? e.g. users are allowed to change navigation and site title with Gutenberg, but not the overall header layout (parent column blocks)?

@themezee

@kjellr Will it be possible for theme authors to lock certain block templates / template parts? e.g. users are allowed to change navigation and site title with Gutenberg, but not the overall header layout (parent column blocks): I’m not sure, but that sounds like it’s worth a new GitHub ticket to discuss. There have been prior discussions and tickets about locking templates and everyone is invited to contribute in GitHub Issue 6993 or open a new ticket.

@greenshady On themes being able to lock certain parts of templates: A good example problem with “no lock” is the nav menu. Nav menus can be complicated to style. Theme authors have to be meticulous in their nav menu design so that it works perfectly across browsers and screen sizes. But, if users can move the nav menu anywhere, it throws a wrench into this perfectly-aligned design the author built. But, if authors can lock, for example, the header layout in place, they can make sure the nav menu in the header is just right. This is not the case with every theme; it just depends on the specific design. I think this has some theme authors worried. FWIW, I think this gets down to the question I originally asked; if themes can lock certain things in place, it gives the theme author back some control. If that happens, we could get more theme authors on board.

@bridgetwes For people creating custom themes for one client — like agencies — I don’t want editors to be able to change the design/general layout of a theme that a design team has crafted for a client.

@allancole If locking things in place means a customer can’t make an edit, i’m not so sure it’s a good thing. But if customers always have the option to roll things back to a Block’s original state then we might get the best of both worlds.

When working with Block-Based Themes are the block-templates and block-template-parts mandatory?

@benlumia007

@aristath The template-parts as far as I’ve seen are mostly used as defaults, so not mandatory. Same thing applies to the block-templates.

Is the long-term goal here to turn a ‘theme’ into a globally consistent collection of config files containing default styles, templates, and starter content?

@modernnerd

@melchoyce I think themes will still be able to provide color palettes, default fonts, even font combos and based on what I’m seeing in GitHub, I think yes, we’re heading this way.

If we’re moving toward Block-Based Themes, is there a need for the customizer? Or, will these things play together in some way?

@greenshady

@kjellr I’m not sure anyone knows the full answer to that question yet. Personally, I don’t think the customizer will disappear immediately, but I do think it’s clear that many of its current duties won’t be necessary in this gutenbergy-future.

@andraganescu it’s unlikely to disappear since all the non-block themes will still use it.

Are there demo sites for the new experimental themes that would make the barriers to contributing / testing quite a bit lower than needing to install the experimental features of GB and each theme. I would like to see that for the future — an easier way to contribute when time is limited.

@Carike

How Can This Meeting Be Most Useful?

@kjellr One idea I have is to have a sort of show & tell with folks who are adopting block-friendly tools and practices in themes today. To help share knowledge and spark more ideas that could come in handy for full-site editing.

@karmatosed I’d love to see what is being built and also what couldn’t be, what are the hitches people found whilst exploring in their experiments?

@melchoyce The shortcomings people are discovering as they experiment are going to be super super important. We need to figure out where this works and where it doesn’t work.

@jffng Would it be worthwhile to have a short section of this meeting where we point out issues / PRs in Gutenberg relevant to the the theme audience? The discussion can remain in github and #core-editor, but kind of a run down of the latest and greatest design and dev happening in this space?

Wrapping up the very active meeting and exchange of ideas @aristath stated: The conclusion I have come to is this: Themes are not going away. They may change, completely transform in many ways. The tools we’re currently using and the way we’re currently building themes is not the way themes will be built next year. But they will still exist, and the new way is neither better nor worse. It’s just different. If we embrace that and open up our imagination, there’s lots of amazing things we — as theme authors — can build.

The next meeting is on Feb 19th at 16:00 UTC. Thank you everyone for attending and sharing so openly and in such a receptive manner.