themes
themes copied to clipboard
Automattic
`blockbase`: Load styles for blocks on render
We went to a lot of trouble to allow loading separate styles for blocks on-render... These changes are part of Gutenberg, and were backported to WP5.8, so it's a shame not to take advantage of them in FSE themes - especially if people start using blockbase as a base for their themes.
This PR adds the ability to load block styles only when needed. To do that, each block gets a separate stylesheet, and these styles are then attached to core styles.
cc @pbking @jffng
Hrm, I'm not sure that it's worth the developmental and transactional overhead myself. The entirety of the CSS is under 40k and can be grabbed in one transmission. Keeping the css separated per-block seems to have a lot of developmental overhead with scripting and such.
I'm keen to hear from others as to the value this adds blockbase.
It depends on what blockbase is... Is it a one-off theme, or is it a base others can use to build their own themes?
If it's meant to be used as a base for building themes, then it might be "empty" now, but won't be for any themes build using it as a base.
As for the scripting: If styles are separate, then a build script is not even needed for them... It's a lot easier to have separate CSS files than it is to have SASS with a build process etc. They're pretty small anyway, so sass + parts don't make a lot of sense - especially since it uses css-vars, which makes sass-vars unnecessary.
Just dropping in a $blockName.css file inside assets/blocks will make the styles for that block get properly added on render, so it's quite simple for devs to do.
Thanks for the PR @aristath :)
We went to a lot of trouble to allow loading separate styles for blocks on-render...
Could you add some context to the performance benefit here?
As for the scripting: If styles are separate, then a build script is not even needed for them... It's a lot easier to have separate CSS files than it is to have SASS with a build process etc.
Fair point, another contributor opened a related issue to discuss this recently: https://github.com/Automattic/themes/issues/3995
If the build steps were removed I might be more open to this, but currently the PR increases the build time / complexity for the theme quite a bit and I'm not sure it's worth the benefit, given that we want to be reducing the amount of CSS the theme ships with over time.
This is a very interesting PR, thank you @aristath I didn't even know that we had the possibility of loading these styles only when needed.
About the sass issue and the need for a build script, it is certainly an interesting one. If someone plans to use Blockbase as a parent theme then the build script is certainly a must have, since it builds the child theme's theme.json merging the child-theme.json file with Blockbase's own theme.json file so that the child theme's json file only needs to have what's specific to it and not everything that Blockbase presets. We did this since there's no built-in inheritance of any kind for the theme.json file on child themes. As for the sass, I tend to agree to keep things simple and not use it when unnecessary (though I really love using partials personally, even if I don't benefit from sass vars) but we are importing some of gutenberg mixins for the breakpoints instead of defining the theme's own breakpoints to keep everything consistent. Granted, that only may not be enough to merit the usage of sass and the discussion is justified.
Quick question, is this on core or does it need the plugin to work?
Block styles in particular don't have any media-queries in them, so they can be plain CSS file... :thinking: Maybe these files could be pulled-out of the compiling process and just live as normal .css?
Quick question, is this on core or does it need the plugin to work?
It's already in core :tada: Or rather will be, once 5.8 is out. I haven't written the blog post on meta.w.org for it yet but I'm working on a draft and the plan is to publish something for this once we reach beta.
Compiled the blocks sass files to css and removed them - as well as their build process.