Sharing some thoughts on the current status for infrastructure/ my interpretation of some infrastructure tasks:

Create the concept of implicit attributes for appearance pairing

It seems the style attribute we are using for colors introduced in #21021 addressed this part we are also using it for lineHeight with success and without the need to register new attributes.

Hook appearance variables to the editor rendering.

It seems this is about making sure styles are regenerated when the structure that holds global style changes. For example, #20530 accomplishes this by compiling the styles on GlobalStylesProvider.

Look at style variations as packages of style attribute sets.

We can achieve this by adding a styles structure to theme.json:

{
    ...
    styles: {
        ‘core/paragraph’: {
            ‘huge’: {
                fontSize: 14,
            }
        }
    }
}

We may also achieve the "Custom User Styles" part of #7551 by just allowing the user to save the current block style attributes as a customization of the theme.json structure.

At this week's Block-based Themes meeting, the group discussed some of the upcoming design tools in this ticket, and whether they should be opt-in or opt-out for themes. Here are our notes:

• If a theme has theme.json, it seems ok to have all new design tools 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.
• We should keep in mind that 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.

More details in the meeting notes.

With the first beta version of WordPress 5.7 not very far away I'm sharing this summary after some discussion with @nosolosw specifying what are the tasks we think should be part of v1 and/or that may be part of v1.

What we will do next?

These are the tasks we will work on and plan to have ready soon. Are the most prioritary tasks.

• Versioning. #27230

  • This needs exploration. One option is that theme.json files have a version number, similarly to block.json files. so if we need to make a breaking change we can still keep code that is able to deal with files from a previous version.

• Child theme support. #25612

  • A child theme inherits theme.json from parents(s) can add new properties or overwrite existing properties.

• (In progress) Padding support on global styles. #27154

• (In progress) Refactor our code and merge it into the core. A PR that started the refactoring #26803.

• (In progress) Improve the way client-side metadata is structured, make sure it matches server metadata shape, and try to avoid metadata duplication. #25138

• Update KSES to accept our link color styles. #25151 Revive: #25411

• (In progress) Expose a structure in the core that wp-cli can use to know what theme.json strings are translatable. wp-cli/i18n-command#224

• Discuss mobile support #24165 and have some double-checking if the current theme.json functionality can work well on mobile.

What we can do next?

Tasks we can work on, it would be nice to have but are not a must and are lower priority may or may not be part of v1.

• Create a JSON schema specification for theme.json. Developers can use the schema to validate if their theme.json files are correct and easily locate errors. Improving the developer experience of using theme.json. We can use the scheme in the core to remove invalid paths etc. #26955

Things for the future

Not part of a first version. Things we may consider in the future.

• Nested styles for semantic contexts. For example, apply a specific base font size for things inside a sidebar. #27233

• Allow CSS properties that we don't manage at the moment. E.g: apply a specific CSS property like textShadow. #27231

Related tasks but that initially will not use theme.json/global styles mechanisms.

• Look into the alignment issues #26633

• Responsive styles/media queries (styles depending on window size). #20244

What decisions do we need to do?

• Are the APIs we offer themes enough to have control about which UI components are surfaced to the user in the global styles sidebar? OR should we expand our API’s? Should our API's allow to specify that the user can change a given style property like line-height at the global styles level, but not at the block level (block inspector).
• If a block does not support something like line-height, but the theme specifies a line-height for that block. Should we output a line-height style anyway?
• What are the controls that are available per block? Which blocks by default have font size available? Which have text color? Which have line-height?

What’s next on the UI/UX side?

The first beta of WordPress 5.7 goes out in January, so we need to have a v1 for the UI ready sometime before the first beta.

• Typography tools are going to be g2 based (or at least some parts like font size control). So we need to merge (at least parts of) g2 in order to have the typography tools ready.

• Extensibility mechanism for 3rd party

• It seems the global styles although functional does not provide a good experience, panels inside panels, a gigantic list of panels (one per each block). What is the plan for the other parts of UI? What are the things we should improve on the UI of these other parts to make them ready for the first version?

  • Navigation between all the different blocks that we can apply global styles to and between the global context.

  • Color options (text, background, and link).

  • Color palette editor.

cc: @nosolosw, @shaunandrews, @jasmussen, @ItsJonQ, @mcsf, @youknowriad

Do you think these solutions are acceptable? Do you have any preferences? Also cc: @nosolosw, in case you have some thoughts.

Yes, I think this is good. I'd love more thoughts on my intuition here though, especially from theme authors, let's not rush implementation.

Do you think need to have for V1 something that allows controlling custom CSS variables (besides color presets and link color)?

Same here, I do think it's a valuable addition especially since you can use this value in different places in theme.json. But I agree it may not be important for V1.

@youknowriad @jorgefilipecosta I've taken your comments here, created an issue to discuss this separately, and added my own thoughts as well. See #27295

It is time for another update on Global Styles :)

Updates on the must-have items

We got some traction on the i18n of theme.json:
#27380
We hope to merge this PR soon. And that should conclude the i18n work of theme.json on the Gutenberg side. It still needs work on wp-cli side to extract the strings. Now we expose a structure that can be consumed.

We also have some updates on the client-side metadata:
#27453 is ready for review.
#27449 was merged.
When we merge the remaining PR, that part of the work for v1 is done.

Regarding child theme support, that work was put on on pause as @nosolosw referred:

I've seen there's rapid movement in the FSE/templates area and I believe when that's more settled I can resume this work.

Design tools visibility discussion

Regarding the question we had on the last update:

Are the APIs we offer themes enough to have control about which UI components are surfaced to the user in the global styles sidebar? OR should we expand our API’s? Should our API's allow to specify that the user can change a given style property like line-height at the global styles level, but not at the block level (block inspector).

There were some discussions on this issue, and an issue for it was created #27295. Solving this challenge and updating the theme.json shape for this is the biggest priority we have right now. If you have insights for this discussion, please share them on the issue.

UI/UX

The big question we had on the last update was the UI/UX, and on that front, there are important updates.
The first version should implement the prototype that is available at https://g2-components.xyz/iframe.html?id=examples-wip-globalstylessidebar--default&viewMode=story#.
It will involve enhancing many of the current components we have to offer that UI.
The issue to track this UI update is available at #27473. And the part related to the specific components is available at #27331.
After this update, there are several small enhancements we can make to make the user experience better:

• #27393
• #27474
• #27475

Given that we already have considerable progress on the infrastructure part, the UI is considered a high priority. We will give a bigger focus to the UI work. The only two things considered higher priority are the i18n work and the issue #27295 already referred.

👋 Here's the current status for this task.

Latest changes:

• Gutenberg 9.9 will come with a new format for the theme.json, see docs. #28110 #28533
• The TT1-blocks theme has been updated to the new format, although not published in the WordPress repo yet. WordPress/theme-experiments#182 WordPress/theme-experiments#175
• Presets:
  • Set up was added to translate them when declared via theme.json. It won't be necessary to declare them in functions.php as well when this lands in WordPress core. It still is necessary while we iterate in the plugin. #27380
  • Font style, weight, decoration, and transforms are no longer presets. #27555
• Support for new properties at the infrastructure level: border-radius, border-color, border-width, border-style. #28049 #27791 #25791
• UI controls: added padding to the global sidebar. #27154
• Custom spacing has been ported to WordPress core and will be part of 5.7 WordPress/wordpress-develop#951
• Continuous documentation updates, fixes, and general polishing.
• Many blocks were updated to expose more UI controls for style properties.

What's next?

• Immediate: list the new UI controls for styles as a "dev note" for 5.7, so themes are aware of the new things users can tweak #28539
• Immediate: finish some loose ends #27506 #28163
• We've been working towards shipping parts of theme.json to 5.7 #27506 While there was a lot of progress, it proved premature given two outstanding issues that are unresolved in the format: how to express different templates/nested contexts & support the new direction for sidebars (controls that are shown/hidden) #28533 (comment) #27331 Addressing these issues would be our next focus.

Expect some issue triage in the coming days, as well as updates to this issue description.

For the people following this task's updates: the issue description has been updated and there's now a third iteration that includes an initial set of tasks to be developed for April's MVP. All the rest has been moved to the backlog or is done.

Update on this: the core feature we wanted for block supports (see #28913) to be able to absorb more use cases is now working on the buttons block (color hook). There're some loose ends I plan to keep working on in the coming days. There are also more hooks and blocks to support and I listed them as individual tasks on 28913, in case anyone finds time to help with them).

Added two ongoing tasks for internationalization in the issue description. I'm looking at #28163 these days to see what's left / what needs to be done for 5.8.

Update for this week's core-editor meeting:

• Block supports: landed the first implementation that doesn't serialize the block attributes. The overview task lists other properties we should migrate and potential blocks #28913 This is a good place to start looking at for anyone interested in helping with global styles.

• Internationalization. There's going to be some work in the translation areas for theme.json & block supports in the next weeks (@gziolo). See #28783 and #29155

• theme.json. I'm going to resume work on some of the things we wanted to do for theme.json in the next few days #28163

There're some changes coming to the theme.json format as per #29891 I'll update this issue's description and the affected tasks in the next few days.

Update for this week core-editor chat:

• The last round of mockups for the global styles sidebar are live. It has provided a good ground to re-evaluate the theme.json format and there's going to be some formalization of the concept of "elements", see #29891 for details.
• There's ongoing work for translations #29828 and iterate to offer higher-level APIs in the server #29667 #29905
• We landed some fixes for sub-properties (padding) as well #29712

This issue description has been updated to focus on the infrastructure parts of global styles, that we aim to ship in 5.8. The UI tasks have been moved to the backlog for clarity but will be re-evaluated at a later point.

This week in global styles:

• Merged a few important things for theme.json: add a layout config in theme.json, allow themes to use any style via theme.json whether or not the block supports it, translation for custom templates.
• Continue iterating on the block supports mechanism: allow skipping the serialization of border.
• Some bugfixes: 30088.

Ongoing/Next tasks necessary for MVP:

• theme.json: changes to the format
• block supports: make the button block use the new mechanism
• internationalization: labels for UI controls 29155 30075
• extensibility: discussion about the existing filters and how we should enable hooks

And more:

• REST Endpoint for mobile
• Expand border support to color, radius, and width
• Add support for child themes in global styles (not FSE)
• Global Styles label.

Just added #30191 to the list as well (under the theme.json group).

This week's status report: ongoing work for the major tasks necessary for the MVP.

• Continue to prepare the changes for theme.json #29891
• Conversations about the settings for the different editors and mobile
  • #30082
  • #29969
  • WordPress/wordpress-develop#1118
  • #30245

This week's status report:

Shipped

• Block Supports: added a gutenberg_block_has_support helper function and support for padding in dynamic blocks 30322, border for search block #30227

• Fixes: title in the save panel of the site editor 30521, fix for themes without theme.json support but with experimental link color support 30452

Ongoing

• Block supports:

  • border for button block #30194,
  • add border color/style/width properties #30124
  • spacing #30333 #30371

• Theme.json

  • Update format #29891 There's now a draft PR at #30541
  • Conversation about whether and how to expand the use of CSS Custom Properties #29714