Experiment to add Color Customizer Controls to TT1-Blocks

[pbking]

An experiment WIP to add Customizer Controls to TT1-Blocks

Background Color

Dark Mode Support

Experiment Goal: Show that a block-based theme can achieve feature-parity with a non-block based theme without a dependence on the Full Site Editor.

This will show that a theme built using primarily block-based tooling can achieve feature parity with an existing (classic) theme at the point of user customization.

In this way a new improved theme will be able to take advantage of the FSE rather than be dependent on the FSE.

This makes switching between themes, especially between FSE and non-FSE themes a consistent process; There is a common denominator for all themes in this space.

The portions that are customizable could be surfaced in BOTH the Customizer (a common place for all themes) and the FSE.

[carolinan]

I disagree with this idea. It is not an idea that is suitable to test with TT1 blocks.

Until the path for how to combine or convert a "classic PHP based theme" to support full site editing has been set for the FSE/Gutenberg project, making the theme work with the customizer -which is currently "hidden" for FSE themes, should not be a priority.

Eventually, it would make more sense to me, to add support for a full site editing template in Twenty Twenty-One, than the other way around.

[carolinan]

I still feel strongly that one of the purposes of FSE is making it easier to create themes and lower the entry barrier. In that sense, for me, this is a step in the wrong direction because I would not want to encourage theme authors to continue creating custom controls in the customizer, when they can use the controls in the editor and for the blocks, "for free".

But I am very interested in hearing other peoples thoughts. I understand that for a beginner user, switching to an entirely new color system in global styles is a big step, but I am not convinced that being able to do it in two places would be better.

On a very selfish notes, it also makes themes more difficult to test, because we are now mixing fairly advanced PHP code, into what was previously a HTML based theme where all that was needed to test were a couple of templates and a json file. If this was a solution that was proposed in the plugin or core, not a theme, I may be more open to it.

I do agree with moving the colors and theme support from the functions.php to the json file but that would be a separate issue and PR.

[pbking]

If this was a solution that was proposed in the plugin or core, not a theme, I may be more open to it.

That's actually precisely the goal; something like this COULD be a part of theme.json (and NOTHING more; the 'customizer-bridge.php' being something that is part of core or at worst a separate plugin and not part of a theme).

The experiment is trying to demonstrate how "customization points" of a theme can be defined and controlled via JSON exclusively.

[scruffian]

This looks very interesting. Do the changes you make get saved back into the theme.json, or elsewhere?

[pbking]

They get saved in the database and added as "another layer of variable configuration" rewriting what the value of the CSS variables are at run time based on what was stored.

There's also an example of leveraging that stored value in other ways.

[pbking]

I do agree with moving the colors and theme support from the functions.php to the json file but that would be a separate issue and PR.

Opened as #210

[mtias]

I agree with @carolinan there — a theme built with blocks doesn't need the customizer to be customized. Loading such a theme within the customizer paradigm kind of defeats the purpose. It would be the equivalent of the classic editor being able to edit blocks, which is counter intuitive. Blocks need a block editor. The value of a block theme is precisely to have a block editor paired to it so it can leverage direct manipulation and everything that comes with it. A block theme already assumes it was developed with support for blocks, so it should lean on way less code to support, maintain, and review, not more.

The bridge that makes some sense to explore (or consider exploring) is the opposite one: a theme that is not ready to adopt blocks across all its templates can still benefit from aspects of theme.json / global styles within the customizer, widget areas, navigation, etc. The obvious one is to simplify how it deals with add_theme_support regarding the block editor (that is, configuration) but it could also conceivably have some support for the high level global styles UI (link color, etc, which boil down to CSS variables).

While TT1-blocks, as it stands, is an example of a theme that should have no need whatsoever of the customizer it's not clear what about "hybrid themes" makes sense from a user perspective. Being bounced around different interfaces is incredibly confusing and one of the main things we are aiming to overcome, so loading a site editor or customizer interchangeably for different resources based on what they support could be a rather undesirable outcome in many circumstances.

[pbking]

a theme built with blocks doesn't need the customizer to be customized

That's the inverse of what I'm trying to demonstrate, that a theme build with blocks doesn't need the FSE to be customized (and potentially that customization layer can be expressed exclusively through theme.json).

A block theme already assumes it was developed with support for blocks, so it should lean on way less code to support, maintain, and review, not more.

I wholeheartedly agree. Making themes this way is better. Waaay better. Which is why they shouldn't need to wait for (and especially be exclusively dependent on) the FSE. And is why the the "customizer bridge" should be a part of core.

Being bounced around different interfaces is incredibly confusing and one of the main things we are aiming to overcome.

Unless there is a common interface to interact with themes then so long as there are CLASSIC themes and BLOCK-BASED themes at the same time on the same system then there will be two distinct and non-overlapping interfaces. Allowing a user to use a new fangled theme, but still be presented with an interface they are familiar with, seems like a really good win for the migration of users.

The proposal isn't so much that there are two places to do the same thing, rather two places that do different things. The Customizer (for all themes) for high-level simple controls to customize pre-determined aspects of a theme. And the FSE (for those themes that can) which is for low-level controls to customize any aspect of a theme. And swap template parts, and more.

[megphillips91]

I agree and see both sides of this issue. For me, the customizer offers a nice "separation of concerns" for a content creator.

Remembering the origins of content management systems - the "why" we needed them in the first place - and in consideration of feedback from FSE Outreach Experiments which clearly shows that understanding what "level" or "layer" the user is saving is confusing to people - it seems the customizer offers a clear trigger to a new editing/saving scope.

For me, in my personal experience, opening the customizer is a clear trigger that I have entered a new workflow and even a new role that has permission to make sitewide effects vs. affecting one post, page, or product. Particularly when we consider mobile, touch, or small screen experiences clear departures and hard transitions between scope often create better experiences and the opportunity to open more real estate in a natural and intuitive way.