Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Discussion] Improve block-styles loading #27671

Closed
aristath opened this issue Dec 11, 2020 · 2 comments
Closed

[Discussion] Improve block-styles loading #27671

aristath opened this issue Dec 11, 2020 · 2 comments
Labels
CSS Styling Related to editor and front end styles, CSS-specific issues. [Type] Discussion For issues that are high-level and not yet ready to implement.

Comments

@aristath
Copy link
Member

aristath commented Dec 11, 2020

In #25220 we split the assets loading for FSE themes. That was an amazing first step and a great improvement, it's a huge win for the project's sustainability.
However, it did highlight some things that could be further optimized in our codebase:

Styles should probably not be defined using their handle

The way styles are defined in the block.json files could be refactored (see comment by @youknowriad in #25220 (comment))
Using the stylesheet's handle feels weird, and a good alternative would be to use the stylesheet's URL or path and auto-generate the handle. Of course if we do that, we'll have to accommodate RTL styles detection as well (maybe a filter would suffice?)

Style dependencies

There is no way to define style dependencies. It may look trivial, but the post-comment-form block for example should have a dependency for the button block's styles so that the form's submit button can be properly styled. Or maybe we should make the style and editorStyle arrays instead of strings so that we may define multiple handles?

Adding block-styles from plugins & themes

Themes & plugins will be adding additional styles to the core styles for core block. Right now the best available method I can think of to add these would be using wp_add_inline_style( "wp-block-{$block_name}", $css ).
This way styles will be added inline only when a block gets rendered. Ideally, we'd have a filter to allow adding multiple stylesheets per block.
But maybe we should add a register_block_stylesheet( $block_name, $stylesheet ) function? Or a filter to allow adding multiple styles per block-type?

Allow inlining styles

In many cases, the stylesheets for core (and possibly 3rd-party) blocks are minimal and no more than a few bytes. The paragraph block's styles for example are ~360 bytes if minified, and gzipped it would be a lot less than that. Making an additional request to get these seems rather wasteful, and small styles like that could very easily be inlined instead.
Ideally, the inlining would happen right after the 1st instance of a block by adding a <style> element. Perhaps a new styleLoadingMethod prop could be added in the block.json file to define how a style will get loaded? Enqueueing the 11.7kb stylesheet for the cover block makes sense, but for the < 1-2kb stylesheets inlining them would be a lot more performant.
A somewhat hacky method to inline all core block styles can be seen in this commit so it's definitely possible to do something about that.

Minify block styles

Minifying block styles would further improve the performance. It can be done on the fly using something like this commit, or ideally we would just minify the files during our builds.

@aristath aristath added [Feature] Full Site Editing [Type] Discussion For issues that are high-level and not yet ready to implement. CSS Styling Related to editor and front end styles, CSS-specific issues. labels Dec 11, 2020
@aristath
Copy link
Member Author

Everything outlined in this ticket has already been implemented so I'll go ahead and close this 👍

@gziolo
Copy link
Member

gziolo commented Dec 20, 2021

Awesome work @aristath 👏🏻

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CSS Styling Related to editor and front end styles, CSS-specific issues. [Type] Discussion For issues that are high-level and not yet ready to implement.
Projects
None yet
Development

No branches or pull requests

2 participants