fix inconsistencies in global styles feature selectors

[tellthemachines]

Trac ticket: https://core.trac.wordpress.org/ticket/65265

This is WordPress/gutenberg#78276 minus a little button width-related logic which is waiting for #12046 to be in.

Use of AI Tools

copied from WordPress/gutenberg#78276 with codex/gpt 5.5 and human-reviewed.

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[github-actions]

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.

Core Committers: Use this line as a base for the props when committing in SVN:

Props isabel_brison, dmsnell, talldanwp.

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

[dmsnell]

@tellthemachines I have pushed updates from my refactor to split_selector_list() from WordPress/gutenberg#79499. I have not updated the rest of this PR, and I noted some @since tags still show 7.0.0.

This will pair with #12306, which I think will break without it (this is due to tests being written which depend on earlier parsing errors, which this PR will now fix).

[tellthemachines]

@dmsnell thanks for the update, but relevant PHP tests are now failing due to a discrepancy in spacing between comma-separated selectors. Could you update your changes to reinstate the missing space? (Or otherwise update the test strings; but reinstating the space would be more consistent with how we treat those selectors elsewhere)

[dmsnell]

reinstating the space would be more consistent with how we treat those selectors elsewhere

@tellthemachines I wrestled with this in the update, because I expected downstream code to expect that each component would start with the actual selector. in three out of the six cases where that’s happening, the call-sites are calling trim() manually, and incorrectly.

we can change it back, but I think it might be less risky if we removed that burden from every caller, particularly because of the demonstrated mismatch between the default trim() characters and those that CSS defines.

either way I will follow up, but what are your thoughts here?

reinstating the space would be more consistent with how we treat those selectors elsewhere

there’s another inconsistency regardless of the spaces which is what to do with things like comments. I left them in here because there was nothing hinting that this method would remove them, but I was trying to follow through with the idea that this breaks CSS selector string into separate strings where each is its own selector, as much as that’s possible without defining these other cases.

[tellthemachines]

the call-sites are calling trim() manually, and incorrectly.

trim() is usually added in places where an extra space might cause breakage to ensure there are no extra spaces. If the characters we're trimming are incorrect we should probably fix them. Unless we're sure that with these changes the strings won't need trimming?

(I haven't dug deeply into this btw, my comment was based on comparing test strings where there are spaces around most comma-separated selectors)

I think it's fine to just update the tests if you're confident this is a better solution.

[dmsnell]

Unless we're sure that with these changes the strings won't need trimming?

If we declare it at the split_selectors_list() method then we can guarantee it; otherwise it will remain a burden for the callees, and also a burden to know which characters to trim.

I’ll update the tests, as I think that will work out more along the lines of peoples’ expectations. Like I noted, there are still inconsistencies due to the mismatch between the mental model of the method “split selectors” and the fact that there may be more than selectors in a CSS selector string.

---

In the process I found what appears to be code that 100% could never work as expected from WordPress/gutenberg#58051 and am trying to understand and address it.

[tellthemachines]

Thanks for the updates @dmsnell! This won't be fully testable in the core dev env until the editor files are synced to include WordPress/gutenberg#79210. But the equivalent changes in Gutenberg are testing well fwiw.

Regarding your observation about comments, I hadn't seen it as an issue because this function isn't used for processing arbitrary CSS, but is only applied on strings that come from block or theme.json-shaped data, which is very unlikely to contain comments. We do know that we don't want comments in selectors 😅 so if there's a chance they could end up in there, it would be worth ensuring they're removed, but I don't think that's something we need to be concerned about right now.

[talldan]

Tests well for me, I set some outline button styles in theme.json like this:

"core/button": {
	"variations": {
		"outline": {
			"@mobile": {
				"dimensions": {
					"width": "20px"
				}
			},
			"dimensions": {
				"width": "300px"
			},

And I can see that the CSS selector for the mobile width is generated correctly:

[github-actions]

A commit was made that fixes the Trac ticket referenced in the description of this pull request.

SVN changeset: 62607
GitHub commit: f5ee2b2

This PR will be closed, but please confirm the accuracy of this and reopen if there is more work to be done.

[dmsnell]

Thanks for merging @tellthemachines — I think I already noted this but I only examined the selector-splitting part and did not attempt to review the rest of the code or update anything.

Really appreciate your efforts; I’ll get the Gutenberg updates merged promptly so everything runs in harmony.