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:

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

Core Styles and Theme Customization: the next steps

Since WordPress 5.9 ushered in the era of 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. themes, there have been questions and concerns about the relationship between theme and CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. styles in the context of 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/. Much of the feedback centers around the notion of how themes can, or should be able to, override CSSCSS Cascading Style Sheets. generated by Core.

This post provides an update about what is happening and, rather imprecisely, when things will happen.

A summary of the challenge

Gutenberg comes with a mix of bundled CSS: global, preset CSS vars, individual block styles or style attributes and block supports.  

As a result of these different layers, theme authors are running into battles of specificity where they wish to override Core styles. Given the frequency of pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party releases, CSS rules are seen as moving targets.

Part of the challenge is to combine the need for greater transparency and predictability with the customization and control of 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.. Thrown into the mix is how the Block Editor approaches and honors styles added by users.

Folks working closely with Gutenberg are thinking about how to address these concerns both in the short and long term. Everyone’s feedback and contributions have been immensely helpful so far. 

As you can imagine, the ambitions are lofty, the parts are many and moving. There remains a lot of work and discussion to undertake, and the answers aren’t all there.

Theme.json and theme CSS

Block themes have introduced a new paradigm into theme development, with Core attempting to absorb many of the common CSS customization burdens that classic themes have had to carry.

This arrangement is apparent at the basic level of pattern and site composition: blocks.

One of the functions of blocks is to express site elements in a consistent manner, and promote consistent customization experience regardless of the theme. This means that site owners can switch between themes and be confident that their theme.json and global style preferences will migrate with little or no friction. 

Overriding CSS, whether layout, preset, or block styles, presents an obstacle to integration and interoperability: visual parity between the frontend and editor becomes more difficult to maintain, upgrades to block internals may conflictconflict A conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved. with overrides. Custom CSS is, furthermore, less portable across other block themes.

By encouraging theme authors to use theme.json APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. where possible, the hierarchy of “base > theme > user” defined styles can be resolved correctly.

The general response to calls for greater control over themes is to extend the theme.json API. If there is a feature in demand, and it’s not currently available in the API, contributors band together to build it in. For example, to control the ways in which editors can interact with their designs, theme authors can define which style UIUI User interface components are accessible in the editor right down to the block level through the block support API.

When working on styles in Gutenberg, these guiding principles have remained predominant.

The reality however, is that theme authors will do what they can to achieve specific objectives, that is, “to get stuff done” and realize their (or others’) designs. There have been reports of overly-specific generated layout styles, and CSS rules using !important frustrating theme CSS overrides.

Alternative ways of thinking about how styles are expressed have been proposed, and the ensuing discussion has been supremely valuable.

While more communication and documentation around the what, why and how of styles is part of the puzzle, making the theory and intentions behind blocks and block themes compatible with the practical reality is an ongoing preoccupation of many who are working on Gutenberg.

Current initiatives

Folks on the Core team, including me, are monitoring discussions, and are actively working on shorter-term code changes, and longer-term mitigation strategies to make working with CSS more predictable.

At the same time, the goal is to preserve the primacy of theme.json, and look for opportunities to extend its API and reduce the need for manual overriding of block or layout CSS. When considering proposals such as extending theme.json to define settings and styles for block “sections”, the goal becomes even more pertinent.

Shorter term changes relate to bugs or enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. features. These potentially include removing !important from preset style rules, and addressing block-specific style issues such as Global Styles: Setting font size for Paragraph impacts Quote Block.

Longer term, there are new discussions around outputting semantic classnames for generated styles and the notion of, for better or worse, holding block or layout classnames to the standards of a public API. The motivation here is for greater consistency in what Core exposes. @isabel_brison expresses eloquently that, regardless of whether something can or should be done via theme.json “sometimes there isn’t a better way to accomplish the goal, and the best we can do in that case is provide a good safety net of consistent and meaningful classnames”.

A vehicle that could unify the management and generation of style and classnames is the nascent Style Engine. The stated goal is to have a “consistent API for rendering styling for blocks, across both client-side and server-side applications”. The barest of bones are in the Gutenberg plugin right now, and there are more iterations on the way. 

Finally, and intertwined with all these efforts, are the plans around increasing layout options. Implicit in this project is a refactor of how we generate and apply layout styles across blocks. Many of the concerns in relation to style and classname generation – predictable and consistent classname hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same., and customization via theme.json – are guiding this work.

Iterations of the longer term projects will be priorities in upcoming versions of WordPress.

Improving documentation

Official documentation on block editor styles is out there. 

There is, nevertheless, huge scope to improve documentation around the role of in-built block CSS and theme.json styles, for example, answering specific questions on best ways to control layouts or individual blocks and providing how-to guides.

It’s a critical one to get right as we all move forward on this issue, and one that I hope will form part of the projects mentioned above.

How to get involved

While there’s no single solution, or maybe even a right solution, now is a great time to get involved while everyone is still experimenting and planning, and there exists the chance for us to strike a balance between the common styles produced by Core and highly specific requirements of theme authors. 

Compromise will arise from wide input and consultation, so I encourage folks to share their thoughts on the features they’d like to see in theme.json and block themes in general. You can join the discussions surrounding semantic classnames, layout options or the Style Engine, or create a new 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/ issue or discussion if you have an idea about a new approach.

If you have knowledge to share that would help other contributors, there’s always scope to expand and improve the documentation

Thanks for reading this post, and for everyone’s input so far. I look forward to diving into the problem-solving pool with you all.


Thanks to @annezazu, @isabel_brison, @andrewserong, @glendaviesnz and @apeatling for their help with this post.

#block-themes, #core-css, #gutenberg

CSS Chat Agenda: January 6, 2022

The next weekly CSSCSS Cascading Style Sheets. meeting is today Thursday, January 6, 2022, 12:00 PM EDT in the #core-css channel in Making WordPress SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.. If there are any other topics you’d like to discuss, please leave a comment on this post.

Meeting Agenda

  • Welcome
  • Announcements & housekeeping
  • CSS Custom Properties (#49930)
  • Other project updates
  • Open floor / CSS link share

See you there!

#agenda, #core-css

CSS Chat Summary: 16 December 2021

The meeting took place here on Slack. @notlaura facilitated and @danfarrow wrote up these notes.

Announcements & housekeeping

  • The next meeting will be on Thursday 6 January at 17:00 UTC
  • @notlaura has been the default facilitator for much of 2021 and will not be able to facilitate as regularly in 2022 so we need help!
  • Please sign up to the Meeting Facilitator schedule document if you can contribute by facilitating this or any future meetings
  • The document also contains notes on how to facilitate the meetings and all are welcome, no matter your experience level!

CSSCSS Cascading Style Sheets. Custom Properties (#49930)

  • In the previous week’s meeting we reviewed the next steps and posted them in the ticket here
  • There are outstanding pull requests to be reviewed before merging into @ryelle’s develop branch
  • Once everything is merged to a single branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". we can start tackling duplication, normalise naming and consolidate repeated values

Other projects

Our other currently active projects are:

Thanks everybody and Happy New Year for 2022!

#core-css, #summary

CSS Chat Summary: 18 November 2021

The meeting took place here on Slack. @notlaura facilitated and @danfarrow wrote up these notes.

Announcements & housekeeping

  • The next meeting will be on Thursday 25 November at 17:00 UTC. Please add your name to the Meeting Facilitator schedule document if you would like to contribute by facilitating this or any future meetings
  • @notlaura suggested breaking for holidays after December 16th and starting up again January 6th 2022
  • @khoipro pointed out that the new meeting time is midnight in APAC which led to a short discussion about meeting times. The conclusion was that we can revisit the meeting time again in the future

CSSCSS Cascading Style Sheets. Custom Properties (#49930)

Thanks everybody!

#core-css, #summary

CSS Chat Agenda: November 18, 2021

The next weekly CSSCSS Cascading Style Sheets. meeting is today Thursday, November 18, 2021, 12:00 PM EDT in the #core-css channel in Making WordPress SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.. If there are any other topics you’d like to discuss, please leave a comment on this post.

Meeting Agenda

  • Welcome
  • Announcements & housekeeping
    • Revisit facilitator schedule
  • CSS Custom Properties (#49930)
  • CSS Audit Improvements & other projects
  • Open floor / CSS link share

See you there!

#agenda, #core-css

CSS Chat Summary: 11 November 2021

The meeting took place here on Slack. @notlaura facilitated and @danfarrow wrote up these notes.

Announcements & housekeeping

Meeting time

  • Last week we initially discussed updating the meeting time to suit people’s schedules better. This week we discussed it further and agreed to try 17:00 UTC.
  • CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. CSSCSS Cascading Style Sheets. Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. will remain on the first Thursday of the month but will now start at 18:00 UTC
  • The next meeting will be on Thursday 18 November at 17:00 UTC. Please add your name to the Meeting Facilitator schedule document if you would like to contribute by facilitating this or any future meetings
  • We’ve added a new Notetaker column to the facilitator schedule – please add your name if you would like to write up the meeting notes! @danfarrow offered to act as a fallback notetaker if nobody else steps forward

CSS Custom Properties (#49930)

  • Last week we discussed updating the targeted release to 6.0, which would give us an --experimental deadline of early next year, unless we manage to get testing done early in the release

CSS Audit project

  • @joyously had asked about the format of colour values in the CSS Audit report and if visibility could be improved. @danfarrow suggested that the values could be moved to appear beneath the colour “chips”
  • @danfarrow also suggested that improvements could be made to the report. Since the report deals with tabular data we could use HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. tables in conjunction with a table library like Filament Group’s Tablesaw to enable responsive, sortable tables
  • @notlaura raised the topic of CSS linting, linking an older comment from @tellthemachines pointing out the core CSS doesn’t adhere to our custom WP config. @ryelle clarified that 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/ is, but not core CSS, and shared ticket #29792 (she added that getting it implemented would involve fixing 6,000+ errors – yikes!)

Thanks everybody!

#core-css, #summary

CSS Chat Agenda: November 11, 2021

The next weekly CSSCSS Cascading Style Sheets. meeting is today Thursday, November 11, 2021, 4:00 PM EDT in the #core-css channel in Making WordPress SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.. If there are any other topics you’d like to discuss, please leave a comment on this post.

Meeting Agenda

  • Welcome (21:00pm UTC)
  • Announcements & housekeeping
    • Discuss meeting time
  • CSS Custom Properties (#49930)
  • CSS Audit Improvements & other projects
  • Open floor / CSS link share

See you there!

#agenda, #core-css

CSS Chat Summary: 04 November 2021

The meeting took place here on Slack. @notlaura facilitated and @danfarrow wrote up these notes.

Announcements & housekeeping

  • @notlaura noted some recent facilitator problems and asked for ideas to improve the situation, suggesting:
    • Continue as we are, with the chance of missed meetings
    • Take a winter break
    • Change the meeting frequency
  • @ryelle responded that the meeting have been helpful to coordinate the custom properties project but maybe the time doesn’t work so well for people, plus the EU daylight savings time change may have caused some disruption

CSSCSS Cascading Style Sheets. Custom Properties (#49930)

  • @ryelle reported that there are still some open PRs to review, and also possibly some files that need to be re-claimed. It also looks unlikely that we’ll make the deadline for 5.9
  • @ryelle added that the planning doc has tasks for late September 2021 which she thinks are still valid. She hopes that we can get some momentum up for 6.0
  • @notlaura agreed that aiming for 6.0, and perhaps revising the meeting time, could help pick up some momentum

Thanks everybody!

#core-css, #summary

CSS Chat Agenda: November 4, 2021

The next weekly CSSCSS Cascading Style Sheets. meeting is today Thursday, November 4, 2021, 05:00 PM EDT in the #core-css channel in Making WordPress SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.. If there are any other topics you’d like to discuss, please leave a comment on this post.

There will also be a CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. CSS Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. starting at 20:00pm UTC, an hour before the meeting.

Meeting Agenda

  • Welcome (21:00pm UTC)
  • Announcements & housekeeping
  • CSS Custom Properties (#49930)
  • Open floor / CSS link share

See you there!

#agenda, #core-css