Global Styles: Confusing UX when styles are overridden from multiple sources

[annezazu]

Description

When using 6.1 RC2 and TT3, I found that I couldn't change the appearance of Headings consistently.

Global Styles have a low specificity by design. This often leads to a confusing user experience though, when configuring default styles doesn't appear to have any effect. This could be due to the new styles being overridden by various sources, e.g. block styles, unexpected markup (see pattern in comments), and even theme-provided external CSS stylesheets.

In such a situation, the preview accurately represents how these elements or blocks would appear on the frontend, and the design tools do generate and apply the correct global styles. The issue is as a user, you could be changing options via the design tools and not see any visible change. This makes them feel broken or that something is wrong.

Original Issue Description

When using 6.1 RC2 and TT3, I found that I couldn't change the appearance of Headings consistently. I don't quite know what's going on here but, if this is intended, we should at least look into removing non working appearance options as it is a frustrating experience to switch between options with no response in the editor. It greatly breaks WYSIWYG.

cc @MaggieCabrera (for TT3) @aaronrobertshaw (for design tools) @scruffian (for element support) in case any of you have insight!

Possible Solutions / Improvements

It might not be possible to detect there are styles that would override settings from a particular design tool to omit it from the sidebar. It also likely isn't possible to accurately reflect that a given block or element has styles from a non-global-styles source that could conflict.

Displaying inline previews related not just on a "per-block" basis but also for root-level elements as well, if possible, might help provide immediate visual feedback that changes are being applied. The user could then easily and quickly compare that preview with blocks or elements in the preview and spot that the blocks in the preview have overriding styles, prompting them to look at more specific levels of applying styles.

Step-by-step reproduction instructions

1. Use 6.1 RC2 & activate TT3.
2. Head to Appearance > Editor.
3. Open Styles UI.
4. Select "browse styles" and switch to a different style variation.
5. Head back to the main Styles interface > Typography.
6. Select Headings.
7. Try changing the appearance options and notice they appear to be applied inconsistently.
8. Inspect headings within the preview via devtools and note that even on "unchanged" headings the heading elements do in fact get the global styles you set applied, they are just overridden.

Screenshots, screen recording, code snippet

appearance.controls.in.font.headings.mov

Environment info

• WP 6.1 RC 2
• No GB
• TT3 across style variations

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

[andrewserong]

This might be one for folks working more closely on the theme development side of things, but I notice that in the TwentyTwentyThree theme.json file, only particular font weights appear to be included in the bundled fonts (I assume to limit the size of fonts that are loaded for the theme?). E.g. DM Sans loads 400 and 700 weights, IBM Plex Mono loads 300, 400, and 700, Source Serif Prop, only 200 and 900, etc. (edit: that last one appears to be a variable weight font, though, so it probably doesn't have the same problem?)

Whereas in the font appearance control, all potential weights are presented in the UI controls. Ideally, I wonder if it would make sense for the appearance controls to (somehow) only show the options of fonts that are loaded? The problem with trying to do that, though, is that it mightn't be possible for the block editor to know absolutely which are or are not available, particularly for themes that load fonts outside of theme.json 🤔

[aaronrobertshaw]

Thanks for the ping @annezazu!

A few thoughts come to mind.

In the your video, you can see that the font-weight is not applied to the headings you're focused on, but the font style is. At first glance, it appears that there are font-weight styles with a higher specificity on those particular headings. This could be because those blocks have applied their own style or a theme has.

When testing this, I could see the font weights and styles were being applied fine to the main site heading on the page. I then added a new heading block somewhere on the page and confirmed those heading styles were correctly applied. Inspecting the headings via devtools confirms the font-weight styles are applied correctly to heading elements.

I could replicate a similar situation to your video when I added a block pattern. The pattern I selected had <strong> tags within the heading. That meant it didn't matter what font-weight I selected for headings because that inner <strong> tag overrode it.

I'm not sure there is a suitable way to avoid this situation where a block pattern looks like it should be updated but "doesn't". Can you confirm that the headings in question on your test site don't wrap additional HTML tags such as <strong>?

To further complicate things, certain blocks may have their own styles. For example, in the demo video below, the Post Title block applied its own font-weight. I also noticed, when switching to the red variant of TT3, the theme introduced an element style for links meaning the post title block's inner link had that font-weight set overriding its parent heading's weight.

Demo.mp4

I don't quite know what's going on here but, if this is intended, we should at least look into removing non working appearance options as it is a frustrating experience to switch between options with no response in the editor.

In terms of the design tools, I believe they are working as intended, although they are a bit at the mercy of themes, patterns, and individual block styles.

[andrewserong]

Thanks for the extra context @aaronrobertshaw! I was too quick in my earlier comment, I think you're right, after further testing it looks like the design tools are behaving as expected to me, too.

In testing, the global headings controls provide the lowest specificity fallback settings for headings, allowing block-level settings in global styles to override the base headings settings, and as you mention TT3 ships with a font-weight: 400 rule for the post-title block which outputs the following:

Further, I could replicate the problem with the Three columns of text core pattern, which includes <strong> being set within the rich text field for the heading links. So the behaviour (while confusing from the perspective of using global styles) is expected that the pattern here would override globally set font-weight settings 👍

I believe they are working as intended, although they are a bit at the mercy of themes, patterns, and individual block styles.

Agreed. The overall usability challenge here for someone new to WordPress, or installing a pattern or theme from scratch, is that it's hard for the user to know what's happening at any particular level without doing some digging. When we make things from scratch, it's easier to have a mental model for what's happening. Perhaps this is something for patterns and themes to be careful with, finding the right balance between opinionated styles within the pattern, and giving flexibility to the global styles design tools.

[annezazu]

Thank you all! I updated the title (or tried to) to be a bit more descriptive of the fact that the UI needs to better reflect the reality. It's SUPER confusing right now to not know what can and can't be used.

[aaronrobertshaw]

Appreciate the continued discussion @andrewserong and @annezazu 👍

I've split the font appearance control, potentially offering font-weight options that are not included in bundled fonts, into a separate issue (#45136).

While it's something that would be great to address, it's secondary to the root cause of the confusing UX in Global Styles, being highlighted in the original issue description. On that note, I've updated this issue's title and description to hopefully better capture what the confusion is and what it's caused by.

Please feel free to tweak any of this as you see fit 🙂

[carolinan]

Perhaps the heading block, site title, post title & archive title, should have panels under Styles > Typography > Headings, not only Styles >blocks > block name
And if any of them are styled they could have a "dot" to indicate that. Like the edited templates have in the template list.

[aaronrobertshaw]

Perhaps the heading block, site title, post title & archive title, should have panels under Styles > Typography > Headings, not only Styles >blocks > block name
And if any of them are styled they could have a "dot" to indicate that. Like the edited templates have in the template list.

I wonder how much this muddies the waters further. For example, if we are overlapping blocks with elements, should we be doing the same for links and link-dependent blocks?

In addition, the dot, in that case, would only indicate some other global style has been set. It wouldn't cover situations where a block's styles or markup override element styles, and external CSS stylesheets enqueued by themes also wouldn't be reflected. We could easily end up with a situation where there should be a dot to indicate some styling be we can't detect it.

I'm unsure about adding something users might think they can rely on but ultimately can't. It's a little like making a promise we can't keep.

[annezazu]

This confusing experience emerged once more with the nineteenth call for testing for the FSE Outreach Program:

I tried changing the Post Title size in Typography and it remained the same. It was the same with text color for the same block. I am assuming there is CSS in the theme overriding this and not a bug persee?

Here's a video showing the experience and reflecting the confusion that continues!

post.title.styling.mov

[maffi-git]

I'm in favour for Carolinan's suggestion to mark set styles with a dot. I'm just developing a theme and try to find out what overrides what. This way I could at least tell, that some styling has been set.
However I'm facing a different issue with my headings and colors that are overridden by a cover-block-style.

[annezazu]

More feedback related to the current experience from the FSE Outreach Program's Build a Block Theme exploration:

I had adjusted the font size under Styles -> Typography -> Text to be higher than the default one, however it would not apply to all blocks in the content. I had to manually update Post Date, Categories and Tags. For the Post Author and Post Content blocks changing the font size to a custom of 21px did not have any effect on the block. For the post content block, the font size is set at the surrounding div, but does not apply to the paragraph child elements, as there’s a default CSS p { font-size: 16px }, which came from a the font size setting in the Paragraph block, as I found out after some testing. I wonder where the 16px from came from, either from the Create Block Theme or some default setting in WP?

[jameskoster]

@annezazu do you think we can close this in favor of #49278? Communicating the hierarchy in the block inspector will indirectly solve this issue because you'd be able to switch between that and the Styles panel to learn why the global styles are being 'ignored'.

A separate solution would be offering a way to view the given block in isolation while you work on it in global styles. Crude mockup:

That's probably a larger undertaking though.

[annezazu]

Let's do it and be sure to incorporate the feedback from here into there!