This post summarizes the latest biweekly Block-based Themes meeting, held in the #themereview Slack channel on Wednesday, 20 May, 2020, 16:00 UTC.
You can find the agenda here. Facilitator: @jffng
Updates
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.
Gutenberg 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 CSS” 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 JSON 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 core 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
emorremfrompxbecause 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.
WordCamp EU Contributor Day
Tuesday June 2 @ 17:00 UTC For the theme team, most of the afternoon will focus on FSE and Block-based Themes.