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

[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.

[ironprogrammer]

Speaking from experience, in my agency days doing (now "classic") custom themes I typically created a private page as a style guide, which was quite similar to the Style Book. It wasn't intended for editing, but for visual reference and to ensure we had all the major elements covered. There may or may not have been liberal use of Save+Refresh while dialing in the stylesheet 🫣.

I like the idea of having this as a utility for any classic theme. It shows off some coolness that block themes get, but also reveals what elements/blocks you might have missed in your styles. It could be a subtle hint to upgrade to theme.json or a block-based theme to get all the benefits.

For those used to working with classic themes, I don't think there's much of an expectation of being able to live-edit with a design "preview" feature like this.

[tellthemachines]

the current thinking is that by having a theme.json file in a Classic theme that this marks an explicit opt in and, #66851 (comment) @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

I think it needs to be very clear that, in its current iteration, the style book doesn't include any editing UI.

What is being discussed for future iterations is how to expose parts of the global styles UI for hybrid themes that have a theme.json. There are a couple possibilities:

• The presence of a theme.json with settings should automatically expose parts of the global styles UI related to those settings.
• An explicit opt in should be necessary to expose any of the global styles UI, in addition to a theme.json.

Based on the feedback in #41119, I'm more inclined towards the second option, as theme authors may want to leverage theme.json for styling purposes without necessarily exposing edit functionality. Having controlled editability is one of the reasons for creating a hybrid theme instead of a block theme in the first place.

I'm very curious to hear what other folks have to say on the topic!

[annezazu]

Ah yes! Let me update to make that far clearer. Thank you.

[t-hamano]

I think the important thing here is that theme.json is not taken into account to determine if the current theme is a block theme, i.e. if the global styles UI is available. If only the templates/index.html and style.css files exist, the theme is treated as a block theme and can access the site editor and global styles.

Considering that, relying on the existence of theme.json is at least a little confusing to me. Also, classic theme developers may develop themes based on theme.json but not want the global style UI to be available. In fact, I also develop many classic themes with theme.json for clients as a freelancer, but the purpose is to define block styles without adding CSS styles, and I do not want the global style UI to be automatically exposed.

Personally, I prefer the following approach:

• Expose Style Book for all classic themes. Explain with more detailed text that the Style Book cannot be edited.
• Add theme support for classic themes to be able to use the global style UI. For example, something like add_theme_support( 'global-sryles-ui' ).

Or, to show/hide some UI, we might be able to consider the following approach in theme.json:

{
	"version": 3,
	"settings": {
		"typography": {
			"showGlobalStylesUI": false
		},
		"color": {
			"showGlobalStylesUI": true
		}
	}
}

[jasmussen]

I've prefixed most of my feedback on this issue that I do not feel strongly about this, and think that folks who feel more strongly about this, should decide. So I'm happy to support either direction. I did want to respond to this:

Considering that, relying on the existence of theme.json is at least a little confusing to me.

The motivation for relying on the existance of theme.json comes down to a few aspects:

1. Followup updates to the Style Book are meant to progressively unlock features for classic themes. Add a palette array, and you get edit access to color palettes. Add a font sizes array and you get access to editing typography, and get access to the font library. Etc.
2. Having the initial opt-in be about the presence of the theme.json file leans into the fact that this is the same file that you will need to edit, to make the style book editable.
3. It avoids another theme support property to keep track on.
4. It has this opt-in, as opposed to an opt-out, because I still think having Style Book as an interace that vaguely resembles the customizer, but isn't editable at all, is going to be more confusing than not having it.

Ultimately, I do feel strongly about letting users opt into editable aspects of the style book. But whether the style book itself is opted into our out of, I'll defer despite the stated not-so-strong opinion.