Skip to content

Feedback on adoption approach for exposing editable UI for the Style Book for Classic themes #68036

@annezazu

Description

@annezazu

Context:

As of Gutenberg 19.9, the Style Book is now exposed to Classic themes. As it stands, support is available for Classic themes that either support editor styles via add_theme_support( 'editor-styles' ) or have a theme.json file. Without either, the Style Book doesn't display anything useful. Here's a quick demo using Twenty Twenty-One:

tt1.style.book.mov

In particular, the current thinking is that by having a theme.json file in a Classic theme that this marks an explicit opt in and, to quote @jasmussen, "edibility is progressive, insofar as if your theme.json is empty, or virtually empty, little to nothing would be editable. But for each array you add, whether that array is empty or not, would unlock part of the interface." For example, if you add settings.typography options, this would then give a user access to the UI for Typography and, potentially in the future, the font library.

With all of this in mind, another PR is open to enable the Style Book regardless of whether a classic theme has theme.json or supports editor styles! All of this begs the question and points to needing to get right the opt in and opt out approach to provide the most value when it comes to exposing editable UI to users of classic themes. This issue seeks to gather that feedback to ensure we can come to the best decision possible.

Feedback needed

From what I can see we have two main tension points:

  • Do we rely on the presence of editor styles or theme.json to opt in OR expose to all and provide a way to opt out?
  • Is there value in showing a non editable Style Book and is that an experience users will understand? In the comments on this issue, the desire for this is clear but I am noting this for comprehensiveness as there's a concern that this could be confusing for users in situations where nothing is editable.
  • Does the presence of a theme.json with settings automatically opt a theme into exposing parts of the global styles UI related to those settings or is an explicit opt in necessary to expose any of the global styles UI, in addition to a theme.json?

Please share feedback on the current approach and the desired approach you'd like to see. cc @WordPress/outreach & @WordPress/block-themers for good measure.

Metadata

Metadata

Assignees

Labels

Global StylesAnything related to the broader Global Styles efforts, including Styles Engine and theme.jsonNeeds DecisionNeeds a decision to be actionable or relevantNeeds Design FeedbackNeeds general design feedback.[Feature] Style Book[Feature] ThemesQuestions or issues with incorporating or styling blocks in a theme.[Status] In discussionUsed to indicate that an issue is in the process of being discussed[Type] FeedbackIssues that relate purely to feedback on a feature that isn't necessarily actionable

Type

No type

Projects

Status

🦵 Punted to 7.0

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions