The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: beafialho <[email protected]>
Co-authored-by: carolinan <[email protected]>
Co-authored-by: aaronrobertshaw <[email protected]>
Co-authored-by: richtabor <[email protected]>
Co-authored-by: jasmussen <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Similar to the dusk variation, the outline button, when placed in the section style with the light background, has no visible border 🤔

Similar to the dusk variation, the outline button, when placed in the section style with the light background, has no visible border

Is there a solution for this?

I think the border needs to be set to the same color as the button text.

I think the border needs to be set to the same color as the button text.

I believe I don't know how to do that in each section style. If someone can, I appreciate the help.

I did not know about it either before Rich suggested it here: #142 (comment)

Oh typically, variations inside variations inside variations 🤯 do not work:

Are there any plans to add this in 6.7 @aaronrobertshaw ?

I think the best alternative, is for all outline buttons in the twilight variation to have the border set to "currentColor".

But that would mean that on top of style 2, the outline button would have an orange border:

"core/button": {
				"spacing": {
					"padding": {
						"bottom": "4px",
						"left": "14px",
						"right": "14px",
						"top": "4px"
					}
				},
				"typography": {
					"fontSize": "var(--wp--preset--font-size--large)",
					"letterSpacing": "0px",
					"textTransform": "uppercase"
				},
				"variations": {
					"outline": {
						"spacing": {
							"padding": {
								"bottom": "4px",
								"left": "14px",
								"right": "14px",
								"top": "4px"
							}
						},
						"border": {
							"color": "currentColor"
						}
					}
				}
			},

Thanks for the ping 👍

Oh typically, variations inside variations inside variations 🤯 do not work:

That was a conscious decision made early on in the section styling explorations. Essentially there are a lot of inception-like issues that can occur. It also greatly complicates sanitization and any future Global Styles UI for users to customize block style variations or create their own.

Are there any plans to add this in 6.7 @aaronrobertshaw ?

None for 6.7.

I'd have also thought there were no plans to support it for any future release at this stage. Of course, with enough valid use cases and some creative design ideas for the Global Styles IA and UI, any of this can be revisited.

The case of outline buttons is a tricky one. On one hand they are a block style variation like the one you are trying to create. Variations are supposed to be able to be applied in a nested fashion rather than "styled in a nested fashion" if that makes sense. I can definitely see the argument for how you are trying to accomplish this but unfortunately, I don't have any better ideas than the one Carolina shared off the top of my head.

Thank you for the quick response.

Without very careful styling, these combinations can quickly become an accessibility problem. It is not unique to this style but also the default.

One thing I have thought about is that if the theme has 5 section styles, there is no way to turn them off.
Just as an example, maybe in the twilight variation, I only wanted to have 3 section styles.
Or maybe I need 7.

One thing I have thought about is that if the theme has 5 section styles, there is no way to turn them off.

The ability to deregister a style variation was touched on a few times during the initial iterations on this feature. There are some complications to this around potential merging and filtering of theme.json data as well as block style registration via register_block_style with style_data supplied.

I think this is something that we want to be able to support but it needs more time and exploration. It won't be something that makes it for 6.7 but hopefully progress can be made in the somewhat near future though.

Without very careful styling, these combinations can quickly become an accessibility problem.

Each theme style variation should account for each section style individually, and support the same number as the parent.

They do, if the border on the outline variation is set to the current color, a style that @beafialho approved yesterday.
So this PR can now be merged.

The remaining exception is the hover style for the outline variation. And as you know, this is a limitation in the editor/ global styles.
I spent about 4 hours on looking into how to solve WordPress/gutenberg#55359 but was not able to.

They do, if the border on the outline variation is set to the current color, a style that @beafialho approved yesterday.
So this PR can now be merged.

I question if we should include full style variations. That's double to maintain (the color set, typography set along with the combined style). If anything perhaps it's the very last thing we do; to try to reduce the burden.

Without the combined variations, there is no way to preview and highlight the combinations that Bea has created.

I would like to see atleast some of the combined / full variations to be included before WCUS contributor day on Tuesday since there are two table leads who have notified that they are planning to test the theme.

Preview changes

You can preview these changes by following the link below:

• Preview changes for twentytwentyfive

I will update this comment with the latest preview links as you push more changes to this PR.
⚠️ Note: The preview sites are created using WordPress Playground. You can add content, edit settings, and test the themes as you would on a real site, but please note that changes are not saved between sessions.

In style 1, The white text color on top of the orange background has a too low contrast ratio:
FFFFFF and FF6442 has contrast ratio 2.93:1, it needs to be 4.5:1 (3:1 for large text).

If the color was changed to base, it would pass the contrast requirements. It does not in my opinion look as nice but other options would mean changing the palette colors.

Noting Rich's comment here which probably applies here as well. I sense the instinct is to get color palettes and typography presets ready first, and then build the style variations from those after the fact? CC: @richtabor in case I'm missing nuance.

Quick question: I've applied section styles to a variety of patterns to test these out in a post. But in the site editor, those posts as parsed through its query loop, no longer include the section styles. In fact, even patterns that are meant to be full-wide are compressed to the center column. Am I missing something obvious here?

Otherwise, Twilight looks good to me. Carolina notes that Style 1 doesn't pass contrast ratios, it's not quite 3:1 which would work for large text. It's tricky too, I'd tend to agree that the way to go is to invert the text color to be black on the bright orange, so the orange remains a vibrant spot color, rather than needing to be darkened/muddied to work with white text. I wonder if #ff7a5c would work as an accent color here instead? So instead of this:

It would be this:

Noting that Bea is AFK this week, so anything we can do to move these forwards, let's commit and branch off her work if need be!

About the color palettes and presets not being complete: They have been in the theme for several weeks.
It is not until testing with these global style variations that any issues that are unrelated to the button outline variation has surfaced.

As a reminder, the theme needs everything that is not a bug fix to be included on Friday, to have time to prepare the trac ticket to include the theme on Monday, before Beta 1 on Tuesday.

Quick question: I've applied section styles to a variety of patterns to test these out in a post. But in the site editor, those posts as parsed through its query loop, no longer include the section styles. I

I can reproduce that too after updating to Gutenberg trunk. Seems like a pretty bad editor bug with the style variations.

In fact, even patterns that are meant to be full-wide are compressed to the center column. Am I missing something obvious here?

It sounds like you have one of the alternative templates active on which ever template is being viewed.
I think that is by design.

I found more color differences between the palette and the global style variation:

In the palette, accent 2 and secondary are the same color.
In the global style variation, accent 3 and secondary are the same color.

The complete new palette would be:
Base #131313 -Body Background, button text
Contrast #ffffff -Body text, button background
Accent 1 #4b52ff-Button hover color background
Accent 2 #ff7a5c
Accent 3 #252525
Primary #ffffff
Secondary #252525
Opacity 20 #ffffff33

There are two duplicate colors.

I opened a new Gutenberg issue to suggest referencing palette and typography presets to avoid this duplication: WordPress/gutenberg#65594

Some observations after merging the latest changes from trunk.

Default templates:
Because the category was moved below the post title, I don't think it should be uppercase anymore:

The button text size and the search block text size feels to large:

Same sample content with sizes decreased to medium:

Category after the changes:

The spacing around the search may still be too large?

Spacing looks okay, there's still something around the inner padding of the buttons, pending the outline button discussion (where as noted I'd rather temporarily sacrifice editor editability of the button hover state, than the outline style).

I meant that the padding inside the search input and search submit button is too large.
Maybe the padding around the regular button is not large enough.

The buttons have a blue border on hover which is not correct, I will try to fix that and then merge this for easier testing.

In Figma, the default (filled) button should be light text on dark background, but in this PR it is light with dark text, but I don't know what was changed on purpose.