block-library/style.min.css was added without wp-block-styles supprt in theme

[mahnunchik]

Describe the bug

block-library/style.min.css styles was added without setting add_theme_support( 'wp-block-styles' );

To reproduce

Steps to reproduce the behavior:

1. Open any frontend page of WP 5.4 without add_theme_support( 'wp-block-styles' ); enabled.
2. Expect styles /wp-includes/css/dist/block-library/style.min.css?ver=5.3.2 added to the page.

Expected behavior

No block-library styles except if set add_theme_support( 'wp-block-styles' ); according to documentation https://developer.wordpress.org/block-editor/developers/themes/theme-support/#default-block-styles

Editor version (please complete the following information):

• WordPress version: 5.3.2
• Does the website has Gutenberg plugin installed, or is it using the block editor that comes by default? default
• If the Gutenberg plugin is installed, which version is it? default

Desktop (please complete the following information):

• Browser chrome, safari, any

[mahnunchik]

If I understand correctly wp-block-library styles are enqued regardless 'wp-block-styles' support by theme. https://github.com/WordPress/WordPress/blob/master/wp-includes/script-loader.php#L2464

Theme may already includes necessary block styles. So I think there are should be way to remove duplicated styles by add_theme_support( 'wp-block-styles' );

[mahnunchik]

It would be nice to have options:

1. Include both wp-block-library and wp-block-library-theme if theme doesn't support blocks.
2. Include wp-block-library if theme supports blocks but requires default styles.
3. Do not include any default styles for blocks if theme have full block compatibility.

What do you think?

[jasmussen]

Hello! Thanks for the ticket. Yes, some block styles are enqueued regardless of theme opt-in. This is necessary for many blocks in order for them to function at all, for example the Columns block relies heavily on complex CSS flex rules, and would not be columns at all unless it came with some basic CSS styles.

On the other end of the spectrum, the Paragraph block should not come with any styles at all, perhaps obviously.

In between those two extremes is a gray area that has changed a fair bit since the editor project started 3 years ago. Back then, very few themes styled the figure or figcaption elements at all, yet those elements are heavily used by blocks such as embed and image. So the block editor provided some baseline styling to these.

As the editor and themes have matured, this has been adjusted, and numerous styles have been moved to become "opinionated styles", that includes things like a left border on a blockquote block, things like that. Those opinionated styles are what you opt into, when you declare support using add_theme_support( 'wp-block-styles' );.

It does not seem feasible to omit styles if a theme declares itself to have "full block compatibility", because you might install a block from a plugin, like the Columns block, that simply does not work without structural CSS.

So instead of a blanket opt-out, I would encourage opening individual tickets for each style you feel should not be part of the default block style, but should be moved to "opinionated". You can CC me on such tickets, and I'll be sure to categorize them properly!

[mahnunchik]

Hi @jasmussen Thank you for explaining. Now I understand the history and use cases of these two styles.

But I have the idea to discuss.

full block compatibility I mean then theme author or during deep optimization of the existing theme is necessary to include the same basic styles in theme itself. Needs:

• Combine all styles into single css file to optimize count of requests.
• Override default styles (without size increase due to unused styles).

So including additional default styles is not necessary.

Of course as a theme developers we may dequeue this styles:

add_action('wp_enqueue_scripts', function () {
	wp_dequeue_style( 'wp-block-library' );
});

I think it will be useful to have mention in the documentation about default styles (not default opinionated styles as is for now) and impact of removing it.

[jasmussen]

Combine all styles into single css file to optimize count of requests.

Agreed. I think the ticket to follow there is this one: #5445.

Override default styles (without size increase due to unused styles).

Absolutely, it's pretty important that the styles provided by blocks and indeed the editor are as unspecific and easy to override as possible. There are two good tickets to follow for developments there, #11779 and #10178. An additional recent development is the idea of putting the editor in an iframe (#21102), which might allow the editor to reduce specifity even further. In addition to that, a recent feature was merged, #19701, which will enable blocks in the editor to have markup that is more similar to the rendered markup on the frontend, further simplifying the styling of blocks.

Hope that helps!

[mahnunchik]

Thanks,

Actually #5445 describes different issue of building specific bundles form used on page blocs. I do not find it useful to create 2^N bundles and kill cache in pre HTTP/2 era.

I mean more simple block-library/style.min.css + avesome-plugin/style.min.css + my-theme/styles.css concat to single and the same file for the whole site.

[jasmussen]

Ah yes. But it does seem like related aspects have popped up in conversation on that ticket, and so as to keep related things together, I would recommend you comment on that thread.

[mahnunchik]

@jasmussen Yep, done! Some thoughts #5445 (comment)