Global Styles: Styles specificity and users expectations

[Copons]

CSS is hard; getting it right while translating it into a user-friendly interface is even harder.

In a GS world, the site's styles can originate from many, many sources: editor default, theme.json and style variations, Global Styles of various nature, individual block styles, custom CSS somewhere, etc.

It's a confusing scenario for the end user, even if tech-savvy, who might not know those sources, or understand how they interact with each other.

In a recent test we ran, we discovered that there's a subtle but important difference between "blocks" and "elements" that I personally never fully realized before.

While in most cases all our design tools affect blocks, these items here affect actual HTML elements:

It is reasonable, technically sound, and translates visually what we used to do in code, in CSS or in the theme.json.

Though, when rendered, element customizations have a lower priority than block customizations.

Again, this is technically correct: HTML elements are more generic than blocks, and it's just right that block styles have precedence.

But it's also very confusing how we have element customization items in the main GS panel (so in a top-priority position) that, when changed, might not do anything to the canvas.

It is a common scenario that themes explicitly define styles for the Heading and Button blocks, which will always override any changes in the Global Styles' elements panels.

I wonder if we should de-prioritize the location of the element panels, since they are technically less !important (CSS pun intended) than literally everything else in the GS panel.

---

cc a bunch of people related to GS that I know of: @carolinan @annezazu @scruffian @MaggieCabrera @mikachan @oandregal @jorgefilipecosta

Context: this rabbit hole started here and continued here, before finally landing into this issue.

[MaggieCabrera]

/cc @WordPress/block-themers

[MaggieCabrera]

I'm not sure changing the order of the panels is a good solution for this. It will help the user that wants to edit a site, but maybe not one who is building one: a case where you want them editing from the global to the specific. I wonder if there's a way we can inform the user where changes from a block are coming from, so they don't need to think about the "cascade". Maybe this information could only be shown in Global Styles in the cases where overrides of styles are possible? I guess that can get convoluted really fast...

[MaggieCabrera]

I can also think of cases where elements are the only way (so far!) to edit the styles of a block partially: this is the case of the search and file blocks. Burying the option to change elements can end up being confusing or having the user change things twice, once in the block and then in the element, defeating the purpose of having the more global solution.

[mtias]

Yeah, the order and hierarchy is fine, it's just that we should display when there are Block Type styles set by the user or theme that are relevant for the category element you are in — if you are editing the "Headings" element we should show and allow access to the Heading, Post Title, Archive Title, Site Title blocks, etc.

Buttons is the same — when editing the generic element we should show the block type in context and as a shortcut.

[mtias]

Also related: #44361, #44420.

[Copons]

I know that notices are a lazy solution, but maybe reminding that element styles are overridden by block styles could be a good start. 🤔

it's just that we should display when there are Block Type styles set by the user or theme that are relevant for the category element you are in — if you are editing the "Headings" element we should show and allow access to the Heading, Post Title, Archive Title, Site Title blocks, etc.

I'm having a hard time visualizing this in my mind, especially in a way that wouldn't overload info.

[mtias]

Similar to the bottom part here:

[dsas]

#45086 is related to this