Accordion heading toggle CSS overrules theme.json CSS

[justintadlock]

Description

#73032 added some new default CSS to the Accordion Heading block. Previously, it was easy to style via theme.json. The new CSS now make it harder to style and introduce the same problems that have made it tough for theme authors styling Core blocks over the years. The Accordion block was free of this until this commit.

The following is an example of how this change now makes it too hard to style the Accordion Heading toggle where it was previously easy. It specifically looks at an example with padding, but it looks like the other styles introduced should produce the same issue.

To correct this, any styles need to be lower specificity than those produced from theme.json (or the Styles panel in the Site Editor).

CC: @t-hamano

Step-by-step reproduction instructions

Here is some basic padding on the toggle:

{
	"styles": {
		"blocks": {
			"core/accordion-heading": {
				"css": "&__toggle { padding: var(--wp--preset--spacing--40) var(--wp--style--block-gap); }"
			}
		}
	}
}

Fortunately, this works. However, the :hover and :focus additions now break this style because of this CSS:

.wp-block-accordion-heading__toggle:focus, 
.wp-block-accordion-heading__toggle:hover {
	background-color: inherit !important;
	border: none;
	box-shadow: none;
	color: inherit;
	padding: var(--wp--preset--spacing--20, 1em) 0;
	text-decoration: none;
}

So, you'd think you could just be more specific with the theme.json CSS:

{
	"styles": {
		"blocks": {
			"core/accordion-heading": {
				"css": " .wp-block-accordion-heading__toggle, .wp-block-accordion-heading__toggle:hover, .wp-block-accordion-heading__toggle:focus { padding: var(--wp--preset--spacing--40) var(--wp--style--block-gap); }",
			}
		}
	}
}

This produces (formatted for clarity):

:root :where(
	.wp-block-accordion-heading .wp-block-accordion-heading__toggle, 
	.wp-block-accordion-heading .wp-block-accordion-heading__toggle:hover, 
	.wp-block-accordion-heading .wp-block-accordion-heading__toggle:focus
) {
	padding: var(--wp--preset--spacing--40) var(--wp--style--block-gap);
}

But that still doesn't work because the new Accordion Heading toggle CSS still has a higher specificity.

Of course, !important will work, but that creates a host of other problems like making it harder to overrule via block style variations.

Screenshots, screen recording, code snippet

Shown here while hovering one item:

Environment info

No response

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

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure

[justintadlock]

Just noting that it definitely overrules the background color I use on the toggle when hovering/focusing, too, which is using an !important for some reason:

background-color: inherit !important;

I missed this earlier because I was so thrown off by the padding shifting when hovering.

Why are we still using !important in Core styles at this point? This is making it very hard on theme authors to style things.

[t-hamano]

Thanks for the report.

Why are we still using !important in Core styles at this point? This is making it very hard on theme authors to style things.

See: #73032 (comment)

Achieving both the customizability of block themes and the definition of default styles in classic themes is a very difficult task, so if you have any ideas, we'd love to hear them.

[justintadlock]

See: #73032 (comment)

Achieving both the customizability of block themes and the definition of default styles in classic themes is a very difficult task, so if you have any ideas, we'd love to hear them.

Yes, move the CSS to TT1.

That's an issue with the theme and should be addressed there. It's a losing battle for Core/Gutenberg to attempt to preemptively fix CSS problems in themes. It has never worked and never will because there's always another problem unaccounted for. It only creates barriers for users and theme authors trying to add custom styles. The best thing we can do is address the issues at the source.

[t-hamano]

See: #73032 (comment)

Achieving both the customizability of block themes and the definition of default styles in classic themes is a very difficult task, so if you have any ideas, we'd love to hear them.

Yes, move the CSS to TT1.

I'm not sure we have the time to do this in the 6.9.0 release. We need to at least test all default themes, not just TT1, and address any issues that need to be fixed if we lower the CSS specificity.

I think it would be best to address this in 6.9.1 or 7.0. What do you think? cc @mikachan @sabernhardt

[aaronrobertshaw]

I'm a bit late to this issue sorry. It was unfortunate that the new block library styles forgot about the Global Styles 0-1-0 specificity requirements.

Achieving both the customizability of block themes and the definition of default styles in classic themes is a very difficult task, so if you have any ideas, we'd love to hear them.

According to the inline comments on the linked PR the higher specificity was only for classic themes. Could there be some middle ground by adding these default styles to the block library's classic stylesheet:

https://github.com/WordPress/gutenberg/blob/trunk/packages/block-library/src/classic.scss?

[t-hamano]

@aaronrobertshaw Thanks for the feedback!

According to the inline comments on the linked PR the higher specificity was only for classic themes. Could there be some middle ground by adding these default styles to the block library's classic stylesheet:

https://github.com/WordPress/gutenberg/blob/trunk/packages/block-library/src/classic.scss?

This approach looks good! However, I noticed that the Gutenberg plugin isn't overriding this style, so we need to fix that first. See #73580