Global Styles: Setting color for List block impacts Post Template block

[annezazu]

Description

This was found as part of the eleventh call for testing for the FSE Outreach Program:

Next up I clicked through the Styles options and decided to change the background color of the lists block. This resulted in the entire background of the posts list to change the background color. I was expecting that only the actual lists blocks would change when adjusting this setting, instead the entire page background of the query block changed. There’s already an issue about adding a “wp-block-list” class to the lists block and I created a PR for this too.

This is the PR referenced: #36676 cc @oandregal as a heads up.

Step-by-step reproduction instructions

1. Open site editor and ensure a Query Loop block is placed within.
2. Open Styles > Blocks > Lists > Colors. Set a background color.
3. Notice the background color of the post template block changes within the query loop.

Screenshots, screen recording, code snippet

list.styles.bug.mov

Environment info

• WordPress 5.9 beta 3
• TT2
• No Gutenberg.

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[oandregal]

👋 I don't know if this is a bug or a feature, so asking for feedback to the hivemind: @mtias @youknowriad @jorgefilipecosta @jasmussen @carolinan @kjellr @jffng

The reason why this happens is that the styles for the list block use the ol, ul selector --- this is, its styles aren't scoped to a particular block but to all ol and ul HTML elements of the page. When the list block was introduced we didn't assign it a class name, such as .wp-block-list, hence, we can't now use that to scope the styles. The same happens with the paragraph (uses p HTML tag and not wp-block-paragraph) and headings (uses h1 et all and not wp-block-h1).

The common view so far has been that this wasn't an issue because paragraphs, headings, and lists are foundational pieces of other blocks. It was convenient that they behave like they are. However, now that the styles are being surfaced to end users, it's been asked again. It reopens the conversation as to whether the current behavior still matches our mental model (and we need to educate people) or it's no longer true. Should we change how the styles of the list block work?

We could do #37528 which applies the styles to any ol/ul element that doesn't have the .wp-block-* class. Note, however, that the fix is limited: the styles will still be applied to any HTML tag that doesn't have a particular class (hence, internal lists of blocks will still be considered "list blocks").

Thoughts?

[carolinan]

To make the changes, one first has to navigate to Blocks in the global styles sidebar. Then, one has to select the "list block" and not simply "list" (the heading for the area is Blocks).
There is no feedback from the UI, no indication or help text, that the style changes affect all lists and not only the list block.
That is why the style changes are unexpected for lists that are not the list block.

While the post template it is semantically a list on the front, users might not perceive it is a list, for example, it does not present with bullets, and the connection between the list block and the post template is too vague, which makes this feel like a bug
(And users should not need to know what HTML tag is used).

There is an issue and pull request to add the CSS class to the list block, but I think what you meant was that it will break with older versions of Gutenberg/WP.

[jasmussen]

Excellent issue, excellent thoughts. To echo Carolina above, my first instinct here is that the list markup used for the post template is an implementation detail that might or might not change the future, and should therefore not be affected by changes to the List block.

[mtias]

Fine to make this more specific. We can output whatever classes we need, but let's not serialize them.

[jasmussen]

With #37940 and #37941 merged, I wonder if this one can't be closed as fixed?

[annezazu]

I am in agreement with you! Closing (after confirming it works as expected).