Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sidebar Controls & Component System #27331

mtias opened this issue Nov 27, 2020 · 10 comments

Sidebar Controls & Component System #27331

mtias opened this issue Nov 27, 2020 · 10 comments


Copy link

mtias commented Nov 27, 2020

The first half of this year brought some needed updates to the design language of blocks, with a strong focus on improving the block footprint, toolbar system, and the inserters. (See #18667, #21080.) Now it’s time to revise the state of block controls primarily used in the sidebar and its underlying component set. This is the next widest topic for the evolving design language.

Kudos to @ItsJonQ @jameskoster @jasmussen @pablohoneyhoney for helping put this overview together.

The sidebar — while secondary in some regards to the block canvas and toolbar — still provides essential tools for interacting with blocks. They also compose the majority of what has been named WordPress Components which also allow building front-end interfaces beyond blocks. As such, the sidebar has grown to accommodate all sorts of controls and design tools...


Most of these elements have grown organically as the block and usability demands increased, going through multiple iterations and isolated refinements. The combination of different component primitives (buttons, selects, sliders, and so on) has also allowed third party blocks to build all sorts of tools. However, it has also resulted in a somewhat disorganized and not always consistent use of patterns which end up hindering usability. (See #26976, #26001.)

Two ongoing core projects (Global Styles and Design Tools) are increasingly demanding more order and design attention to these controls to improve its usability, grouping, hierarchy, and overall design. It’s no longer sufficient to do it piecemeal like with gradient tools (#21269) and cannot be done just in the context of global styles — it is also important to consider these sidebar controls as they scale and adapt cohesively to other realities of the editor.

Block Controls

Looking at the current state of global styles design, it is quite evident that what has emerged so far results in a somewhat convoluted amount of interface disparities and behaviors. Following the footsteps of the block interface, this issue aims to work on its underlying elements and its composition to help the design evolve more coherently. We have enough material now to also focus on the clarity of actions for each typology of control, given more clear hierarchies and expectations, and its impact on a refined set of interface components. (Of note, the different interfaces for resetting controls as a good example of disorganized growth.)

Related: #27295, #16479.

Typography tools, concretely, have been expanding with different blocks requiring a slightly different subset (with or without line height, with or without font weight, etc). These groups of controls need flexibility and clarity. Both themes and blocks need to be able to specify which elements are configurable by the user and the interface needs to be able to accommodate different configurations in a pleasing and consistent manner.

That means there are two complementary goals with this effort: an improved design system and more functional control typologies that neatly organize the complexity of information and actions. We can start with some of the basic and most recurrent panels that can provide a baseline for others.


The block editor initially supported custom font sizes alone. At the current moment, typography tools include presets, custom sizes, line-height, font-weight, custom units, etc. These tools need to be designed together to provide the right amount of emphasis and order. (See #23767, #26060, #26844, #23908.)

Reusable text styles can be defined in the theme scope (or global styles) and then applied to any block that includes the typography panel. This flexible system will allow users to manage the majority of the typographical rules at a site in the same place, and wholesale changes can be applied with speed and efficiency. Interacting with any block’s typography setting will be more intuitive.


Text styles act as presets for the individual typography controls and so can be as simple or complex as needed. Detaching a text style on a per-block basis for a one-off treatment is as simple as changing a value.

Of note, the ellipsis button reveals a menu of per-control toggles for the typography panel. This affordance allows blocks to show or hide only the most appropriate controls as a default, and for users to exercise more specific typographical designs in just a couple of clicks. This also prevents the interface to grow uncontrollably as the included tools expand.

For example, a Paragraph block may only expose the size control initially, but if a user needs to change the font as well (and this is allowed in the theme.json configuration), that would be possible without overwhelming the majority of users. In reverse it works the same way – removing a control unsets it, and the block will inherit the appropriate value from the theme and global styles.

This should then be both highly configurable and adaptable. To summarize, the following needs emerge:

  • A well defined grid.
  • Configurable presence of controls with resets.
  • A set of components including steppers, unit + slider, dropdowns, and toggles.


Related: #24049, #19785, #8171.

The next panel to focus on are color tools. This is another example of a group of tools that has evolved naturally as the editor began supporting solids and then expanded to include palettes, custom picker, and gradients. It’s widely used by core blocks and third party blocks, which can register color settings for more than one element — with text and background being the most prevalent options. That means we need to accommodate the color tools themselves as well as clearly communicate what they apply to.

Color palettes is another important dimension, which allows themes or site managers to define an explicit color palette and lock down custom colors if desired. One challenge that has emerged is the need to allow theme color to be in addition to rather than in replacement of the default color palette. With global styles also allowing user configurable palettes, it’s important the design accommodates multiple palettes as needed.

  • Communicate the current role of a color.
  • Support solids, gradients, and custom picker tools.
  • Allow for multiple color palettes.

The color tools are highly idiosyncratic in their function, which is a good test case for the design language to cover.



The tools to configure the spacing of a block are among some of the most incoherent tools we offer, with controls usually scattered across different panels and standalone tools. (See #23770, #24874, #26368, #22956, #14747.)

The proposed dimensions panel emerges as the consolidation of controls relating to the space a block occupies on the page. This includes but is not exhausted by height, padding, width, possibly alignment, and so on. Much like the typography panel, these controls are not always going to be present for every block, so it’s important individual controls can be toggled on and off as required, and that blocks can expose those that are considered default options based on configuration. The focus in this exercise is to test how the different controls ought to be laid out.


Component System

Related #24341.

These three cases are a catalyst for rehearsing and expanding the emerging WordPress component system and its design. No systems can be done in a vacuum, so it’s important to develop a robust feedback loop between the demands of the application and its design consolidation. There will be a separate issue outlining how we could continue to improve on the tools in a backwards compatible way while introducing higher-level APIs for block authors to rely upon instead of needing to use the primitives themselves. This effort of higher level component APIs has been quite successful with the block toolbar, offering both ease of use, good dev experience, consistent behaviours and a higher accessibility floor.

Screenshot 2020-11-27 at 12 15 08


The design showcased here is a work in progress and very much open to feedback.

@mtias mtias added [Feature] Design Tools Tools that manipulate visual aspects of blocks. [Feature] UI Components [Type] Overview labels Nov 27, 2020
Copy link

ItsJonQ commented Nov 27, 2020

Thank you @mtias , @jameskoster, @jasmussen, and @pablohoneyhoney !
This is incredibly exciting!

Addressing these issues is at the heart of the "G2 Components" project. It provides the architecture, systems, and code that embody the spirit of streamlining and elevating the UI experience within Gutenberg and WordPress 🙏 .

I have a handful of coded prototypes that showcase some of the designs mentioned above.
I think these prototypes would be helpful in demonstrating some of the interactions and flows we're imagining for Global Styles/Block settings - starting with the Typography Tools.

Typography Tools Prototype

I have another prototypes that provides a peek the Components / Design Systems aspects of this initiative.

Input Prototypes

Note: At the bottom (left), there's a handful of controls that allow you to try out various modes and themes - features that are supported from the core Style System.

🧬 Integrating the new Component System

Integrating into Gutenberg gracefully with minimal disruption was an absolute requirement from the beginning (along with other "must haves").

Once G2 Components matured, and we felt confident with the architecture and direction, we started planning and preparing for integration.

I recognize that there's a lot when it comes to G2 Components.
That is why I've been open and transparent about it's design and development from the beginning.

You can find the code in the G2 Components Github repo.
I try to most updates + share ideas at least once a week on the G2 Components project blog.
I've also been giving updates during core chats in the WordPress Slack.

Lastly, I've been doing live design/code (almost daily) sessions on Twitch. There, I often walk through parts of the system, explain design decisions, and answer any questions that come in from the chat.


Copy link

In case anybody would like to play with these designs in Figma, I added the components we worked on to the WordPress Design Library as proposals.

Copy link

Just to clarify, would this let the Drop Cap option still have its own panel / color options, but just have them be consistent with other available options? I think that would be nice and would resolve this request as well as another I spotted while searching for this conversation.

Copy link
Member Author

mtias commented Dec 1, 2020

More customization settings for the drop cap would be a separate ticket. I like what Apple Pages is doing with them:


Copy link
Member Author

mtias commented Sep 6, 2021

There's an updated overview issue focused on global styles that expands on this one to further detail: #34574.

Copy link
Member Author

mtias commented Dec 2, 2021

This has been largely put into practice through wordpress/components additions & refinements, plus the work on both Tool components and the global styles interface.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
[Feature] Design Tools Tools that manipulate visual aspects of blocks. [Feature] UI Components [Type] Overview
No open projects

No branches or pull requests

6 participants