Block editor styles: initiatives and goals

The CSSCSS Cascading Style Sheets. rendered by the blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor needs improvement.

The challenges are many and they have been documented. There are, nevertheless, several recurring themes:

• An overabundance of rendered inline style tags and duplicated CSS rules. For example, see #41434.
• Confusing or meaningless classnames, or the lack of semantic and utility classes. See the proposals in #38719 and #38998
• Difficulty extending and customizing styles for themes due to high specificity. Touched upon in this post, and demonstrated in issues such as #40159, #36135 and #37590.

The purpose of this post is to highlight ongoing initiatives targeted at addressing these issues, and to outline longer-term ambitions to output more readable, efficient and extensibleExtensible This is the ability to add additional functionality to the code. Plugins extend the WordPress core software. frontend styles. 

Roadmap

Phase 1: block styles consolidation and refactoring the layout abstraction

Goals:

• To audit and consolidate where the code generates block support CSS in the backend so that they are delivered from the same place (as opposed to multiple places). This covers CSS rules such as margin and padding, typography, colors and borders. 
• Removing repetitive layout-specific styles and generating semantic class names for each layout. 

Phase 1 is currently underway. 

The focus in Phase 1 has been to lay a foundation that will make it easier to introduce iterative improvements. 

Rather than printing block styles on demand from multiple locations, the focus is to create a single, centralized agent responsible for generating them, and, in later phases, assume the responsibility of processing and rendering better frontend CSS.

Work on this has started and is progressing well. See Tracking: Add a Style Engine to manage rendering block styles #38167.

A pull request that reduces rule duplication and institutes semantic class names for the layout block support is ready for review. It also centralizes layout definitions, which will pave the way towards adding additional layouts in the future.

See: Layout: Use semantic classnames, centralize layout definitions, reduce duplication, and fix blockGap in theme.json #40875

Phase 2: global styles consolidation and reducing style tags

Goals:

• Connect global styles to the same mechanism with which we’re generating block styles.
• Reduce the number of inline style tags we print to the page for block, layout and elements support.
• For layouts, use a presets-like approach to generate semantic class names for attributes of layouts.

Building upon Phase 1, the outcome of this phase is to have a single styles “generator” capable of building CSS for both block and theme.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML./global styles.

In Phase 2, the objective is to explore how we can leverage this consolidated system of style generation by first grouping, then rendering a minimal set of style tags to the page. 

This includes, for example, moving block supports styles such as layout and elements to a single style tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.), then identifying other candidates for optimization.

There are already some very early, investigative PRs:

• Style engine: register styles for enqueuing and rendering #41424
• Style engine: output global styles CSS rules using selectors #40955

With regards to layout support, extending the group of semantic/utility classes to combine common attributes such as content justification and orientation, further reducing repetitive layout-specific styles.

Phase 3 and beyond

Proposed goals (in no particular order and not exclusive):

• Continue with style consolidation, address edge cases or unique blocks that require special handling, such as the Gallery block.
• Explore pre-render CSS rule processing with the intention of deduplicating other common and/or repetitive block styles.
• Extend the scope of semantic class names and/or design token expression, and encapsulate rules into stable utility classes.
• Establish and document standards by which to extend/override CSS.
• Propose a way to control hierarchy and specificity, and make the style hierarchy cascade accessible and predictable. This might include preparing for cascade layers until they become more widely supported, and allowing for opt-in support in GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ via theme.json.
• Allow for rendering styles in asynchronous contexts. See #35376

The intention is to publish GithubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ discussion threads for these topics to gather ideas and feedback.

How we’re going and how we’ll get there

The expectation is for the layout refactor and much of the styles consolidation work mentioned in Phase 1 to ship in WordPress 6.1. 

Phases 1 and 2 aim to ameliorate pain points, and also set things up for future enhancements in Phase 3++.

Style nirvana might well be out there, however the path comprises individual stepping stones, discovering how individual parts contribute to the whole, and balancing compatibility and stability with innovation.

If we can keep refining and narrowing the scope, shipping in stages, and laying out the foundations, I think we’ll be in a better position to manage the risks and challenges and greatly improve the condition of our rendered styles and frontend output. 

Thanks to all the folks who have shared their wisdom so far. ❤️ If you’d like to contribute, or have feedback or ideas on present or future initiatives, please leave a comment on one or all of the ongoing projects I’ve linked to in this post. 

Acknowledgements: This post was co-authored with @andrewserong and @isabel_brison, with the assistance of @apeatling and @matveb.

#core-css, #core-editor, #gutenberg