[WIP] Design Tools: Add section based styling via theme.json #56234
Conversation
aaronrobertshaw
added
[Type] Enhancement
|
This pull request has changed or added PHP files. Please confirm whether these changes need to be synced to WordPress Core, and therefore featured in the next release of WordPress. If so, it is recommended to create a new Trac ticket and submit a pull request to the WordPress Core Github repository soon after this pull request is merged. If you're unsure, you can always ask for help in the #core-editor channel in WordPress Slack. Thank you! ❤️ View changed files❔ lib/block-supports/sections.php ❔ lib/block-editor-settings.php ❔ lib/class-wp-theme-json-gutenberg.php ❔ lib/experimental/class-wp-rest-block-editor-settings-controller.php ❔ lib/load.php ❔ phpunit/class-wp-theme-json-test.php |
|
Size Change: +1.35 kB (0%) Total Size: 1.7 MB
ℹ️ View Unchanged
|
|
I didn't check the code or anything, just reading through the documentation of the PR. The thing I'm wondering is:
I guess what I'm saying is that a "section" is very close to a "style variation" that is shared across blocks maybe. So I wonder if we should introduce a new concept/attribute... or find a way to have a new type of style variation. I'm not totally convinced yet but curious if you thought about this. Curious about thoughts from others @oandregal @mtias @mcsf |
|
Themes would define section styles in theme.json, as well as within corresponding style variations. So each variation would have different section styles, just like each variation can have different colors, gradients and duotones. |
aaronrobertshaw
force-pushed
the
try/section-styles
branch
from
524adcd
to
b4ee591
Compare
|
Thanks for questions and discussion @youknowriad and @richtabor
I did consider the potential overlap in concepts here. As Rich noted, the idea was that these section styles could be overridden by theme style variations, making them distinct in that regard. Another approach I looked at was whether the individual block type style variations could accommodate these section styles by allowing the variation to define their own nested In addition, I had a discussion with @SaxonF, @tellthemachines, and @andrewserong about where in the theme.json a new I hope that provides some extra clarity. Nothing is set in stone yet so any further questions or ideas are more than welcome! It would be great if we can finalize a direction on this soon though to ensure we can deliver an MVP for WP 6.5. |
This reverts commit bc6d240.
Also fixes incorrect font family and sizes config in stylesheet test
|
👋 Read the original issue to understand the why and this is what I see:
|
I can see how retaining section assignments when switching themes may be a nice, theoretically desirable goal. But in reality, I also don't see how it could / should work in practice. Limiting the available types of sections one could defined would be severely limiting and make this feature useless for anyone trying to push the boundaries a bit. And "randomly" picking a replacement section from another theme when switching also seems like a not ideal experience. |
|
Took a look at the proposal and a bit of the code to understand the data flow. This is what I see:
{
"styles": {
"sections": {
"default": {},
"hero": { /* any valid style (color, border, etc) & elements (button, heading, etc) but not blocks */ },
"dark": {},
"light": {}
}
}
"supports": {
"section": true
}
<style>
/* Styles generated from theme.json */
.wp-section-brand { }
</style>
<!-- wp:group {"section":"hero" } -->
<div class="wp-block-group wp-section-hero"></div>Does this sound about right? If understood correctly, it looks very similar to block style variations. Note that I may miss some context, specially regarding how this helps theme switching. However, based on this comment, it seems the only reason block style variations are not a good fit is because they don't apply to multiple blocks at once. I also see that Justin has gotten far by just using block style variations. I wonder if we can review that experiment and streamline the developer experience of block style variations by:
|
|
I'm in complete agreement with @oandregal here. Also, maybe we don't need to support multiple blocks but just "any block |
I feel pretty strongly that we should not define these via slug values. Otherwise, we're back to square one with trying to come up with an unofficial standard of naming slugs, to have a higher level of interoperability across themes. I want to assign multiple section color sets to patterns in the pattern library—then each theme chooses their own color combinations (if any, and however many). |
|
Thank you everyone for sanity checks, questions, and suggestions. My apologies in advance for this wall-of-text reply 🙏 I get the impression there is some confusion of Theme Style Variations vs Block Style Variations in some of the earlier discussion. At least there is for me reading it 🙂
@fabiankaegy, unfortunately, I don’t have something I can link to for this but I can give more of a historical summary if necessary. The conversation currently happening here on this PR, looks like it will cover it all anyway.
@youknowriad, this is what I was saying. The idea was that you might activate a theme, then on a page you might apply different section styles such as
@cbirdsong I like this approach and it would align with being able to configure each high-level category of design token via a drill down or something. I’d avoided this initially to focus on getting a workable proof of concept as I’m wary about scope for WP 6.5. That said, I also appreciate we don’t want to go too far down any path that may box us into a corner.
@oandregal Yes (also thanks for diving deeper and the proposals here)
The current direction was led primarily by the color sets concept. Take a theme with 3 section styles defined. These section styles would be applied via their index e.g. This may work for colors, but I agree 100% that when expanded beyond that things fall apart. It has also been floated that in that fallback logic we could look for matching slugs first before falling back numerically. Personally, I struggle to see this working cleanly in all situations but my understanding was this is pretty important to the idea of colour sets. I believe @richtabor and @SaxonF can speak more on this and offer a better example as to how the non-slug-based application of section styles helps facilitate potential use cases. Another possiblity is that we could scope the section class to a given theme as well, e.g. This limitation would allow switching between a theme’s style variations to update sections but not when entirely switching themes. If applying that constraint, we could do away with the index fallback and simply use a slug. Which if changing the
Correct although,
Correct, these are not bound to any block type. It was intended however that this section support be limited to an allowed list of blocks. To start with perhaps only Group, Columns, Column etc. (The code doesn’t enforce this fully yet though).
Correct. The block with a section style applied gets a class name added to its wrapper. That classname currently though does not use the section’s slug but an index for the, admittedly flawed, fallback side of things when switching themes.
Except that block style variations do not support child styles per block type. I noted in an earlier comment, we could update block style variations to also support a nested Take the following scenario, where we wish to have a hero section. That section should define some tailored styles for the section’s container block, any inner Paragraph, Cover, Gallery, Media and Text blocks within it. It can also define element (or further block type styles) for buttons, headings etc. On some templates the hero section is a Group block, others it’s a Columns block or something. The same section styles should be able to be applied to each of those container blocks (Group/Columns). We also still have the issue of combining block style variations with a section style, e.g. a dark background pattern that tweaks the outline button block style variation (assuming we also add theme.json supported configuration of block style variations)
That was a primary reason, yes. A section style could also define tweaks to a block’s style variations so they make sense aesthetically within the section too. I’m not sure overloading block style variations helps keep things simpler than a new Could keeping section styles separate also make them more portable? Such as being provided along with patterns etc.? |
@richtabor I'm not sure I fully understand how you would want to reference different section color sets in a pattern though. I thought the entire point of the sections is to still use the same color names but swap out the value of them. So in your pattern you would say that the background uses the primary color and the text uses the contrast color. Depending on what section this pattern is then placed in it looks drastically differently. I understand your aspiration of not dealing with random user generated slugs all over the place. But I similarly feel that nameless color sets are going to be very confusing to use. All the examples here so far refer to sections as "Hero", "Light", "Dark" etc. It's like we give names to style variations of themes. Because the name gives meaning to what the section is trying to represent. Do you have any ideas / examples for how you think this could / should work in the UI for nameless sections? I know you've played a lot with this idea and am really curious about how you think this could be solved. Your exploration here https://x.com/richard_tabor/status/1719685837552832979?s=46 seems really interesting though it looks like it also relies on names to indicate meaning 🤔 |
Independently of whether or not we use block style variations for sections, all of these would be good additions! My main devex concern about sections being block style variations is currently having to define them as PHP functions, which splits styling logic between several different places. There's also the question of how the UI would work: would the existing style variations buttons in the block sidebar be used to show the section styles? That might become confusing if we consider
Would every single block now have those section buttons in its sidebar in addition to any other block style variations it may have? (As a side note: it would be convenient to be able to apply section styles to any block at all, otherwise folks using custom blocks won't be able to benefit from this feature) My other thought if we did go this route is that we'll probably have to build in the ability to target blocks inside sections from the start, otherwise competing specificity of existing block styles will make section styling a frustrating experience. For it to work well, I suspect targeting blocks is a must. |
Agreed, a catch here was specificity issues when a block type style applies styles to a selector more specific than a single CSS class e.g.
This PR currently supports block type styles within sections. Some random `sections` config for the theme.json as an example{
"styles": {
"sections": [
{
"title": "Hero",
"slug": "hero",
"color": {
"background": "#034078",
"text": "var(--wp--preset--color--base)"
},
"blocks": {
"core/heading": {
"typography": {
"fontSize": "90px"
}
},
"core/paragraph": {
"typography": {
"fontSize": "24px"
}
},
"core/button": {
"color": {
"background": "#1282a2",
"text": "var(--wp--preset--color--base)"
}
}
}
},
{
"title": "Dark",
"slug": "dark",
"color": {
"background": "#0A1128",
"text": "var(--wp--preset--color--base)"
},
"typography": {
"fontSize": "var(--wp--preset--font-size--small)",
"fontStyle": "normal",
"fontWeight": "600"
},
"blocks": {
"core/button": {
"color": {
"background": "#1282a2",
"text": "var(--wp--preset--color--base)"
}
}
}
},
{
"title": "Light",
"slug": "light",
"color": {
"background": "#F8F8F8",
"text": "#0A1128"
},
"elements": {
"heading": {
"color": {
"text": "#034078"
}
},
"h5": {
"color": {
"text": "#1282a2"
}
}
}
}
]
}
} |
Yes, and that's an argument in favour of this implementation! I meant to argue that any solution using block style variations would be incomplete if it didn't support that. |
|
To move this feature forward, I'll be putting together an alternative proof of concept that extends block style variations as proposed by @oandregal with the suggestions offered by @youknowriad. Some guidelines for the new proof of concept include:
|
I'm not concerned with swapping out values of colors, but to assign different color names to elements. Say use 'theme-3' color as the background color, and 'theme-1' as the text color in one section. And the inverse in another. The theme picks that set of colors for that applied section style, not the block. I'm concerned that if we don't have a way to auto-generate, we'll end up with the same scenario we face with theme colors. That you can't assume color slugs across variations and whole themes. I like how spacing values work, where they are mainly generated by WordPress, and the theme provides its values for each. This way spacing 20 is nearly always the second largest spacing value. If theme A uses "dark" and theme B uses "darker" then those won't map. It's a long shot, but would be nice to not have to worry about interoperability. |
|
Thanks for the follow-up, @aaronrobertshaw I see how sections may seem to be theme switch friendly if we ask theme to use a closed set of slugs such as 
Let's use the above pattern. I created a codepen to illustrate as well, if that helps. By using sections we are able to only serialize the class <style>
/* WHO PROVIDES THESE STYLES? */
.wp-block-group {
background-color: var(--wp-section-color-0);
color: var(--wp-section-color-1);
}
.wp-block-group .wp-block-button {
background-color: var(--wp-section-color-2);
}
</style>
<div class="wp-block-group wp-section-0">
<h2>Visit us</h2>
<p>Our address in Cool Place, 23 street.</p>
<div class="wp-block-buttons">
<div class="wp-block-button">
<a class="wp-block-button__link">Get directions</a>
</div>
</div>
</div>The theme X could provide the following CSS for section 0: /* Section 0 from THEME X */
.wp-section-0 {
--wp-section-color-0: black;
--wp-section-color-1: white;
--wp-section-color-2: purple;
}Now, user switches themes and the new theme provides the following color set for section 0: 
/*
* Section 0 from THEME Y
* that happens to use a black color palette.
* https://www.color-hex.com/color-palette/45492
*/
.wp-section-0 {
--wp-section-color-0: #000000;
--wp-section-color-1: #111111;
--wp-section-color-2: #1e1e1e;
--wp-section-color-3: #3c3c3c;
--wp-section-color-3: #4d4d4d;
}Because the new theme uses a black-based palette, this is how the pattern looks like: 
That's why I'm confused as to how sections help with theme switches. For a pattern author, it's certainly easier to work with classes rather than individual styles. It seems that we want "Pattern Style Variations". However, patterns being just an abstraction for a set of blocks, I still see "Block Style Variations" as the way forward. Though we need the fixes mentioned in the thread: better devexp by declaring them via Note that I've not been involved in design tools for a long time, so I may miss tons of context. Please, do share as much as you think I'm missing! |
|
In addition to "author devexp" when creating block style variations, there's also "user devexp" of current block style variations – when you compare them to style variations the difference is striking:
|
|
Thanks for taking the time to expand on your thoughts @oandregal 👍 I'm currently in the process of trying to work through a block style variation approach to section styling, with some general guidelines mentioned in my earlier comment.
I still agree there are problems.
One thing to note here is the example pattern included the block styles in hardcoded CSS, whereas for the switchability to have any chance those would be defined within the sections themselves (hence noting block style variations must be extended to support block type styles). I understand also that existing patterns or content could have such hardcoded styles that make this all difficult as well. My understanding of some of the assembler work going on was that the idea is to avoid most styling within patterns and rely on sections to provide the styling. I've tweaked the codepen to hopefully illustrate this a little. Again, I'm not trying to advocate that this is bulletproof but instead provide a starting point to evolve from. Screen.Recording.2023-11-24.at.10.21.53.am.mp4
With the potential for several block style variations and the limited real estate in the block inspector, compared with the theme style variation screen in the site editor, we might need to have a threshold at which the block styles UI becomes something other than the collection of buttons it is now.
This can work within a single theme. If we consider switching themes, then I don't think there's any guarantee the colors make sense still and it breaks as it does now. |
Thanks for following up on that. The changes you've done to make the two sections 0 work with the same HTML illustrate my point: each section changed how the colors were mapped to the specific HTML elements. They had to include “structural CSS”, the CSS that maps elements to section colors. They are no longer a “generic” section 0 that can work across themes: it's a “section 0” designed for working with a specific pattern. To be clear, I insist on this because I believe a safe “theme switch” or “pattern style variations” are two different problem spaces. It's best if we don't conflate the goals, and it's fine to only address one right now! |
|
@fabiankaegy this is great feedback, thanks! The three examples you mentioned were in the initial
And we also had
|
|
I've read through #48581 and #48581 as well as @richtabor comments (1, 2). What if we scope "Element color sets" to "providing different color palettes to blocks"? I know this is not the intended goal of that issue (provide a safe "theme switch"). Though I hope I conveyed why/how I don't see that working, and I'd be more than happy to be proved wrong and seeing counter-examples! Providing different palettes to blocks could work in different ways:
{
"settings": {
"color": {
"palettes": {
"light": [ { "color": "...", "name": "...", "slug": "..." }, { "...", "..." } ],
"dark": [ { "color": "...", "name": "...", "slug": "..." }, { "...", "..." } ],
"brand": [ { "color": "...", "name": "...", "slug": "..." }, { "...", "..." } ],
}
}
}
}Each approach has its pros/cons. Probably there are more approaches. In principle, I'd think I'd start with 1, as it leverages what's available already. We'd also need to consider cross-cutting concerns: do we ship all colors defined by all palettes? It's a lot to ship to browsers. Etc. Would this be useful to pattern authors? I keep commenting on this PR, though it's no longer on topic! Happy to go elsewhere that's more relevant :) |
|
Appreciate the continued discussion on these issues @oandregal 🙏 As the potential solutions and issues here diverge, I'm conscious of trying to keep things manageable and break it down into deliverable chunks. Currently, I'm still working on a proof of concept for extending block style variations as proposed previously. My focus will continue to be on that as more of a direct alternative to this PR. I will work on the Element Color Sets feature after that. Thanks again for sharing your thoughts and wisdom on these possible features. 🙇 |
|
Closing this PR given the agreement to go in a different direction. |
|
I've written up an issue to perhaps track and communicate the efforts in extending block style variations better. You can find it here: #56632. If anyone has anything they'd like to add to it, don't be shy 🙂 |
🚧 🚧 🚧 🚧 Not yet ready for review! 🚧 🚧 🚧 🚧
Related:
What?
Provides the ability to style sections of a page with a predefined set of styles contained within the theme.json.
For this initial MVP, there will be no global styles support as that will require heavy UI updates and would be unlikely to make it into 6.5.
Why?
The ability to style entire sections with curated sets of styles will help unlock a level of composability for site designs and further encourage building sites with patterns.
Todo
sectionsconfig within theme.jsonFuture Follow-ups
How?
sectionblock attributeTesting Instructions
TBA
Testing Instructions for Keyboard
TBA
Screenshots or screencast
Screen.Recording.2023-11-17.at.1.26.46.pm.mp4
Sample `sections` config for the theme.json used in above demo
{ "styles": { "sections": [ { "title": "Hero", "color": { "background": "#034078", "text": "var(--wp--preset--color--base)" }, "blocks": { "core/heading": { "typography": { "fontSize": "90px" } }, "core/paragraph": { "typography": { "fontSize": "24px" } }, "core/button": { "color": { "background": "#1282a2", "text": "var(--wp--preset--color--base)" } } } }, { "title": "Dark", "color": { "background": "#0A1128", "text": "var(--wp--preset--color--base)" }, "typography": { "fontSize": "var(--wp--preset--font-size--small)", "fontStyle": "normal", "fontWeight": "600" }, "blocks": { "core/button": { "color": { "background": "#1282a2", "text": "var(--wp--preset--color--base)" } } } }, { "title": "Light", "color": { "background": "#F8F8F8", "text": "#0A1128" }, "elements": { "heading": { "color": { "text": "#034078" } }, "h5": { "color": { "text": "#1282a2" } } } } ] } }