Blockbase: Ponyfill css overrides block-level global styles for Button block

[jeyip]

Description

I'm seeing an issue with block-level global styling being overridden in the dotcom site editor and frontend (atomic + simple sites), and it looks like it has to do with the ponyfill.css file in blockbase. When I remove ponyfill.css, per block global styles work as expected.

List of affected blocks

1. Button (text color and background color)
2. Cover (text color and background color) Not caused by blockbase
3. Site Title (text color and background color) Not caused by blockbase
4. Cover and Group blocks (right/left padding)

Steps to replicate

1. On a simple or atomic site, activate a block theme that depends on blockbase
2. Activate the site editor
3. Navigate to the site editor
4. Insert a button block onto the page and add text content
5. Open the global styles sidebar, and select the "By Block Type" menu tab
6. Unfold the Button block-level global styles panel and select different color options
7. Confirm that the color options do not change according to user customizations

Button Block

Result

User customized global styles (like background color) weren't applied to the block

Expected

The block styles would change according to user customizations

Notes

• Slack Discussion: p1629226103080900-slack-C029FM1EH

[pbking]

The button portion of the related ponyfill is here. That relates to the video shown but it's not the only place where this is happening.

This is happening because many of Blockbase's selectors have a higher specificity than the styles generated by Global Styles. This is especially obvious with the button which has a rich ponyfill system including hover states (which are going to be particularly problematic to address in this situation).

[jffng]

I believe this affects the editor and the view slightly differently.

In the case of the button (ignoring the hover states issue), we could theoretically solve the issue by remove the wrapping selector .wp-block-button and the global styles customizations win because they load later in the cascade. @mikachan and I tested this and it works in the editor.

However, in the view, the theme CSS is loaded after the global styles CSS, so the theme CSS is still winning. This is a mismatch between editor and view, and also not the preferred order. We opened an issue above to see if we can fix this upstream.

Front-end source:

[mikachan]

I had a quick look at this in Gutenberg and then in Blockbase. I couldn't change the order of global-styles-inline-css in Gutenberg other than moving it above wp-block-library-css. I did this in this file by changing the priority like so:

add_action( 'wp_enqueue_scripts', 'gutenberg_experimental_global_styles_enqueue_assets', 999 );

I did manage to force the order via Blockbase, by again changing the priority of the styles in functions.php:

add_action( 'wp_enqueue_scripts', 'blockbase_scripts', 0 );

Which did this:

But I guess this isn't ideal as every theme would need to cater for this.

Thought I'd report back in case this helps in any way, or makes it quicker for someone to work some Gutenberg magic.

[creativecoder]

Thanks for investigating @mikachan !

It looks like WP 5.8 is registering the 'global-styles' stylesheet as well, which is taking precedence over Gutenberg's enqueue calls. But Gutenberg should be able to unregister and reregister the asset to work around this. I'll spin up a Gutenberg PR.

[creativecoder]

Potential fix for this at WordPress/gutenberg#34147. As pointed out earlier, Blockbase styles will still need to be updated to have a css selector specificity equal or below Global Styles css.

[jeyip]

It looks like issues with global styles and the cover block can be attributed to specificity problems in core Gutenberg, and not from themes. WordPress/gutenberg#34150. I'll be taking a closer look tomorrow.

[jeyip]

Issues with global styles and the site title block are caused by CSS specificity conflicts with seedlet-blocks, not blockbase.

• Block level global styles are being applied to the site title through .wp-block-site-title a
• The Seedlet blocks theme has a competing declaration via .is-root-container a:not(.wp-block-button__link):not([download])

themes/seedlet-blocks/assets/theme.css

Lines 148 to 157 in 00ee734

	/**
	* Links in Content
	*/
	.is-root-container a:not(.wp-block-button__link):not([download]),
	.wp-block-post-content a:not(.wp-block-button__link):not([download]) {
	color: var(--wp--custom--color--primary);
	text-decoration-color: var(--wp--style--color--link);
	text-decoration-thickness: 1px;
	text-underline-offset: 0.2em;
	}

I drafted a separate issue and a separate PR to address this.