Where blocks end and themes start #35469
Replies: 1 comment 2 replies
-
|
Good question! Musically speaking, the intention is that the theme is the conductor of the blocks orchestra. The general aim is that we can absorb most if not all the structural responsibilities into blocks, and a large part of the style directives into blocks and elements. We can use the 80% rule there, but in a fairly loose way, mostly as set of expectations. Container blocks adopt positioning and layout responsibilities allowing the theme to focus on composition and styling. It also ensures multiple blocks — including third-parties — compose natively well together. Some relevant issues to read through:
We are still in exploration phase regarding how to adopt grid as a block layout primitive. See #16271 and an early prototype #20000. This is not so much a question of if but a question of how, since these tools need to find an interface expression that makes sense for users. Still, looking at the 80/20 split, it's likely some aspects of this setup are not exposed in UI or even in attributes, and it would be up to the theme to customize. The same applies to global styles. There's no plan to cover the entire CSS spec and is not the aim of system to do so. If we introduce tools for editing shadows, it might not have all the details you can get with the CSS. Our typography tools, for now, won't have things like ligatures, kerning, and other more advanced aspects. However, this is not a hard limit and depends on how intuitive and useful these tools can be for users, and how they can reduce work from a theme. It is important that tools like global styles, theme.json, and generally the block API can get a design 80% there with the block toolkit (in some cases closer to 100%) while still allowing the full breath of web technologies to be available for a theme to do its final frescoing as needed. It also leaves quite a bit of room for block libraries that want to expose a lot more settings or augment the ones provided by core. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, thanks for the detailed response Matías. It does make sense. I especially like this phrase:
I wonder how much of the composition will be pushed to patterns and the patterns directory. It seems like even a better candidate for composition reusability. I'll study the issues you shared and I'll get back if I have more questions from those 🙂 |
Beta Was this translation helpful? Give feedback.
-
|
With how lean patterns are, the main responsibility would still be on blocks to have the necessary capabilities to allow patterns to express their designs. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I'd like to know more about the current plans for blocks and global styles, and how far they will be able to replace the theme's CSS.
Maybe everything is not clear yet, but any insight would be really helpful 🙂
Layout
By layout, I mean positioning elements in the page, like using columns, grids, spacing...
position(static, relative, absolute, fixed, sticky)marginpaddingline-heighttext-aligndisplay(block, inline, flex, grid...)Also including all the extra options for things like
flexorgrid.Basically, I'd like to understand where the limit is going to be between what users will be able to do with blocks and global styles and what devs will need to write in their theme's CSS.
For example, Webflow exposes all the positioning CSS properties in the UI.
CSS Styling
The same question goes for CSS styling properties, like typographies, font sizes, backgrounds, borders, shadows, and so on.
There are already a bunch added as block supports or global styles, but:
Beta Was this translation helpful? Give feedback.
All reactions