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.