Canary Variation: Headings element changes not sticking

[annezazu]

When using a fresh site using 6.1 Beta 3 and TT3, I noticed that when trying to change the heading element for Canary, the changes wouldn't register:

TT3.issue.heading.typography.mov

This seems to vary by style variation though as with other variations it works fine!

[carolinan]

This is probably because the heading block has a style? That the heading block would take precedence over the heading element.

[annezazu]

Can you clarify a bit more? I'm not sure I'm fully understanding. This was a fresh install and I went straight into the editor to try out variations (no local changes).

[carolinan]

The heading block has a style in theme.json:

			"core/heading": {
				"typography": {
					"fontFamily": "var(--wp--preset--font-family--ibm-plex-mono)"
				}
			},

So to change the font family of the heading block, you need to use Style >Blocks > Heading, not
Style > Typography >Headings?

[carolinan]

@mikachan In Canary, is the heading block font family needed? The same font family is set for the body, shouldn't that be enough?
Or maybe the font family should be on the heading element and not the heading block?

[mikachan]

I'm not sure the font family needs to be set anywhere other than the main typography setting at typography.fontFamily now. Perhaps it did before, but this seems to work nicely now. I've updated #279 with the changes.

[Copons]

This is probably because the heading block has a style? That the heading block would take precedence over the heading element.

Hi @carolinan, apologies for breaking into this conversation.

We've been running some tests on Global Styles on WordPress.com, and someone reported an issue that seems to be related to the specificity order between the various sources of styles.

I'm on the fence about opening a Gutenberg issue, as it seems the intended behaviour, but I'm looking for confirmation. 🙂

In that issue, it seems that the theme.json sets, for example, a settings.custom.button.colors.background, that overrides the user's GS -> Colors -> Buttons, which applies to button elements.

Judging by your comment, this seems intended, and I can agree with the technical reasoning.
Although, I wonder if the "Typography / Colors / Layout" items are too prominent in the GS panel, given their specificity is lower than the theme-defined styles.

As a user (even as a tech-savvy one), I could reason with the fact that some of my customizations have "unpredictable" precedence over each other, but I would always expect them to have precedence over theme defaults.

By putting the elements control in the GS' main panel, we might be suggesting that they are a "bigger deal" than what they are in practice.

(FYI I'm well aware of how complicated it is to translate CSS into a user-friendly UI!)

[carolinan]

I am not sure if it is intended, I was trying to reason..around the reason :)
I remember reading comments about the order of elements vs blocks, but it is difficult to search through GitHub. I think the discussion was even about the headings. Maybe @scruffian can remember.

[MaggieCabrera]

I think the block should always win over the element, since it's more specific.

[carolinan]

I agree, but how can we make that make sense to users who do not see their changes being applied?

[MaggieCabrera]

I agree, but how can we make that make sense to users who do not see their changes being applied?

that's much trickier, and probably something worth an issue in GB for discussion. I see this being the case in more than one instance. The user doesn't have to know how a theme is setup and sometimes changes can come from more than one place that the user doesn't know about

[Copons]

Happy to open an issue on Guten (later today) so that the discussion can happen where it's supposed to! 🙂

EDIT: done! ✅