Pseudo selectors: allow in blocks and expose more in the UI

[oandregal]

What problem does this address?

This is the current state of pseudo selectors in the WordPress design system:

Element	Theme (theme.json)	User (UI)
link	All style properties.	Only color.text.
h1	All style properties.	-
h2	All style properties.	-
h3	All style properties.	-
h4	All style properties.	-
h5	All style properties.	-
h6	All style properties.	-
heading	All style properties.	-
button	All style properties.	-
caption	All style properties.	-

What is your proposed solution?

The UI does not need to replicate all and every style implemented by theme.json. However, there are common use cases for pseudo-selectors that we don't support yet. See, for example, this hover effect for containers:

Gravacao.do.ecra.2023-08-23.as.14.48.55.mov

What if we:

• enabled pseudo-selectors for any block via theme.json (connected to the block supports as well)
• allowed users to switch the background color on hover for container blocks

[oandregal]

cc @aaronrobertshaw as I remember you having worked in this area and may have thoughts or past conversations to link to.

[aaronrobertshaw]

Thanks for the ping @oandregal 👍

I haven't done a whole lot with the pseudo-selectors as they were being added by others around the time the Selectors API was being stabilized.

For me, the main issue has been how we incorporate configuring different sets of styles, into the UI. The main issue I'm aware of that is exploring this is #38277.

Another one that might be worth noting is #48581. It introduces the concept of element variations or "color sets", and might involve an overhaul to the information architecture in the sidebar. Both in global styles, and the block inspector.

I'd be glad to see progress on the interactive state styling as things like link hover styles can get in the way of custom button text colors etc.

[oandregal]

There's better issues the reflect the priorities and direction of the project, so I'm closing this one.