The Global Styles Interface

[mtias]

In collaboration with @pablohoneyhoney. Not finalized.

Previously #27473.

This issue covers the broad design aspects of global styles, the upcoming user interface for theme.json. For the broader implementation roadmap check #20331. The global styles interface aims to allow managing design aspects of a site globally and across blocks. The current interface merged in the plugin is merely a tentative placeholder.

Iconography

Global styles will be a crucial component for the set of design tools and deserves a more iconic representation. In the future, there will be flows built into the system allowing you to move from local styles to global — like making customizations to a button block and opting to apply them globally changes across all buttons of that type. To support these flows from within the local scope a recognizable symbol can help guide the different flows as the functionality spreads across more places.

• Closes: Consider the icon for global styles #20873

The initial placement of the tool continues to be in the editor header for the site editing or template editing contexts. As part of the broader explorations on information architecture for the site editing features, direct access is also a possibility.

Structure

Currently the target are four main components to the interface plus a preview:

• Colors.
• Typography.
• Layout.
• Blocks.

Together they represent the formal structure of theme.json. This is designed to allow growing in the future as needs arise, either in core or through extensions. Navigating through sections currently is intended to work as a drill-down pattern to provide more breathing room for the tools and additional focus.

Small previews. One challenge the design aims to solve is the problem of not necessarily seeing what you are affecting because changes are applied far and wide on the site and those elements may not be visible at all times in the larger canvas preview. For example, if you are customizing duotone filters globally but don't have an image in the current view, the user may not be seeing the entirety of what they are affecting. To address this, each panel is structured around a top level abstracted preview. This is meant to capture the spirit of customizations while also providing instant feedback and hierarchy.

Down the road, the capabilities of global styles could expand to provide a more in depth styleguide that can expand across blocks and patterns. While not an immediate priority, it is considered in various issues, including #32682.

• Consider all meta-functions of global styles. This footer menu is not an immediate priority but it would provide access to a variety of functions that are not formally spec'd yet.

• Styleguide.
• Revisions.
• Reset all.
• Export / import.
• Theme / Pattern browsing.
• etc.

Colors

Palettes

The color section encapsulates the ability to visualize and manage color palettes as well as customizing color elements across the site. Currently, there's a single set of color palettes that can be provided at one time, but this is meant to change with the overview at #29568.

• Closes Allow showing default palettes in addition to theme ones #28416.

Following up, multiple sets of palettes would be a possibility, including light / dark splits. The access point for managing color palettes is the following one:

It lists some initial colors for recognizability and the overall number of colors available. Palettes are split between theme (more semantic), default (spectrum based), and custom (colors registered by the user).

There are a bunch of granular combinations that need to be supported, since the default palette ought to be replaceable or disabled entirely. Custom colors could also be disabled globally, which means this panel could look like this depending on configuration:

If available, editing a color palette would work as follows:

Palettes include both solid colors as well as gradients. The gradient tools still need to be finalized:

Elements & Filters

More general descriptions of elements is to be included in the main tracking issues, but this gives a good overview of what aspects are represented. Most importantly, background, text, links, etc, are represented here as elements. (Elements can resolve to CSS variables sometimes.)

• A category of "filters" is split and would allow configuring things like duotone across a site when it should apply beyond individual blocks (like Image, Media & Text, and Featured Image, for example, but not a Gallery). This is a good example of an in-depth feature that needs to connect a block-agnostic context with block specific settings, hence the navigation.
• Filters, such as duotone, need configurable defaults. They are equivalent to a new color palette.

Right now core only supports duotone, and infrastructure work is being done to connect it with theme.json.

• Duotone filter: Allow theme.json to set default filters for blocks #33642.
• Allow for Global Block-level configuration of duotone #34122.

One major challenge also comes in how multiple color states can be represented and accessed as is the case of links. This needs further research to narrow down a UX flow that makes sense while not being overbearing.

Tool

Accessing an element brings into focus the main color tools with an emphasis towards selecting a color from existing palettes. The preview element is used as an anchor point and to provide immediate feedback on interactions. The color picker is a fundamental component of this interface.

• Tracking: Updated ColorPicker #34284.

In the global styles context, the picker opens as a flyout menu:

Typography

Fonts

Managing fonts as site assets still needs a more formal proposal but broadly speaking the design would incorporate a recognizable small preview. This is the corollary to the palette management interface. These sets would be extensible and configurable, ranging from a single default set (current state) to multiple choices.

With support for additional pairings and browsing the UI would evolve to accommodate it. There's a larger surface of issues to work through and figure out when it comes to themes switching and the ability to combine sets from different themes or styles.

An interface for selecting font families is still upcoming as there are quite a few details to get right, including communicating potential performance impact of multiple fonts.

• Finalize UI for selecting and managing fonts.

Elements

Elements naturally operate in the same way as the colors panel does.

• The main difference if the GroupItem contains a small preview of the specific typography attributes applied.

This is updated live to reflect current choices.

Tool

The concrete tools for typography are the same to the one used in blocks and reflect the settings of theme.json. A breakdown of that in more detail:

• Tracking: Typography Tools: Tracking #34345
• The extra addition is a preview area that draws from the preview elements used throughout global styles.

Layout

The last group gathers tools around layout and spacing. In the context of global styles this is reduced to site container attributes. There are several issues tracking progress and improvements on the various layout related tools.

• Alignments Overview #29506.
• Flex Layout Iterations #33687.
• Dimension Tools and Controls #28356 and Improving the Group block Layout panel #34558.

Blocks

The "by block" section is an interface to the more granular theme.json that affects individual blocks across a site. This allows controlling the default settings and style attributes of blocks and renders in a similar way to the block inspector toolbar.

• Include design of inner panel.

It needs to be clear what blocks might have customizations.

[youknowriad]

Just wanted to update quickly here on the progress:

• The sidebar has a new icon now.
• We also introduced the navigation system in Update the global styles sidebar to use a navigation component #34885 it's using the old Navigation components but we're considering switching to new simpler components that offer more UI flexibility in Add new Navigator components and use them in the global styles sidebar #34904

[youknowriad]

The global styles preview has just been added in #34991

[Clorith]

I'm honestly not sure if this is the right ticket for thoughts on the concept of a theme.json administrative interface, but I'll throw it in, please feel free to point me elsewhere if there is a better location.

The concept of an interface here in the first place feels counter-intuitive to WordPress' philosophy I feel ("Decisions, not Options"), we are now potentially throwing a lot of options at users, and they are things the user probably should not be changing in the first place.

The concept of a hardcoded configuration file in the theme is that the theme has made the decisions for the user, the theme authors know what limitations to impose, and which choices the user should reasonably make, this is all part of the themes identity, and by giving users without that familiarity the power to overwrite that within core with a set of button clicks, especially when a lot of the implications of changes here may not be apparent to the average user, I worry this will be a bad experience both to the user, but also theme developers who put time and effort into those decisions.

This is in contrast to how the customizer currently works, to make a comparison I know has been made elsewhere before. In the customizer, the theme has made a conscious decision on what the user should be able to modify, and how, where as here the themes entire set of decisions are exposed to the end user.

I did see the mention of creating some kind of generic previews, but I don't feel those give a realistic representation of what the user is changing in the same way as for example the customizer where you see your actual content would (the exception being if the Site Editor element you're looking at happens

I should make it clear though, as a power user, I absolutely LOVE the idea of this interface (and I really like how it's shaping up by looking at this tickets planned ideas), but this really feels like it would be a prime area for someone to make a standalone plugin for those who want that granular control to override what others have defined, because as a built in feature it introduces a lot of what I will call "potentially dangerous" options (for example the current implementation, which I know is a bit of a placeholder, has no relationship to content, so I can safely now make my text and background clash contrast-wise without the warnings I'd get in the normal block editor, and this change would now be globally acknowledged as the default value, and I would only see the individual warnings inside the block editor it self if I chose to look at the color options for the text I write).

[annezazu]

@Clorith I wanted to chime in to share some thoughts as I've heard some of this feedback a ton with my work with the FSE Outreach Program. Hopefully it helps give wider context and others can continue to chime in as needed. This is not meant to stop the conversation but to continue it.

we are now potentially throwing a lot of options at users, and they are things the user probably should not be changing in the first place.
&
by giving users without that familiarity the power to overwrite that within core with a set of button clicks, especially when a lot of the implications of changes here may not be apparent to the average user, I worry this will be a bad experience both to the user, but also theme developers who put time and effort into those decisions.

Right now, this work is intentionally being done in a way that "illustrates the maximum amount of customization options — the ability to lock down templates, capabilities, design tools, etc, is still a prime focus to account for the different needs of different sites" (From the Status Check: Site Editing and Customization post).

This is in contrast to how the customizer currently works, to make a comparison I know has been made elsewhere before. In the customizer, the theme has made a conscious decision on what the user should be able to modify, and how, where as here the themes entire set of decisions are exposed to the end user.

This will still be the case with theme.json as options are being added to disable options. For example, you could disable the option for users to add Custom Font sizes with a simple line to theme.json:

{
    "version": 1,
    "settings": {
        "typography": {
            "customFontSize": false,
}

These options to disable and "lock down" various pieces will continue to be built into theme.json so theme authors can still do that curation or, conversely, purposefully have things be wildly customizable by users.

Of course, as you mentioned, I imagine there will always be room for plugins to play a role in locking down the interface for folks or, conversely, opening up options more to create a more tailored experience based on the site's needs. For example, perhaps the site administrator wants to use a theme where they can customize every little detail but they want the option to lock those options down for other users on the site.

[youknowriad]

Quick update on the progress above: We've just separate the color palette panel to its own screen in #35109, we've designed the Menu Item as suggested in the issue above, the palette's design itself is still unchanged though.

[youknowriad]

Small update here: The site padding has been added in #35241

[sdwire]

I see a comment "The gradient tool still needs to be finalized."

That's encouraging. I'm not seeing if/where a design discussion is happening. Is there a page for discussing the gradient tool?

One thing I'd really like to see in the gradient tool is to let me select colors from among the solids in the color palette. If l then change the value of a color in the palette of solids, I'd like to see the gradients that use that color automatically updated to reflect that change.

I can't see that this idea has been discussed, and I'm not sure where to plant the idea. Any pointers?

[oandregal]

This allows controlling the default settings and style attributes of blocks and renders in a similar way to the block inspector toolbar.

Just wanted to unwrap this comment. I understand this means that the block list could be organized by block categories instead of being a flat list?

[paaljoachim]

As the customizer is hidden from full site editing themes it would be very helpful to add a custom CSS area to the Global Styles panel. There is an issue for it here:
Global Styles: an input for custom CSS
#30142

[mtias]

Closing this as most of the UI is implemented. Splitting a new tracking issue just for typography at #38534.