Update theme.json: split global block selector into root and defaults #28533
Conversation
oandregal
requested review from
ajitbohra,
chrisvanpatten,
ellatrix,
mkaz and
spacedmonkey
as code owners
oandregal
added
the
Global Styles
|
Size Change: -1.79 kB (0%) Total Size: 1.37 MB
ℹ️ View Unchanged
|
|
I think the use of * here is confusing, it is not immediately clear what this symbol represents. We want FSE to be easy to work with also for beginners, and the switch from plain CSS to a JSON format is not so easy to wrap your head around in the first place. |
| @@ -197,7 +197,7 @@ export default function GlobalStylesSidebar( { | |||
| > | |||
| <TabPanel | |||
| tabs={ [ | |||
| { name: 'global', title: __( 'Global' ) }, | |||
| { name: 'root', title: __( 'Root' ) }, | |||
There was a problem hiding this comment.
Similarly, exposing the term "Root" to non technical end users in the sidebar may be confusing.
There was a problem hiding this comment.
The idea we discussed in #28163 is that we have a lot of things that use the name "global", so it losses its meaning and has created confusion when talking about this. The intent is to walk away from to global to a different name as to bring some clarity in conversations:
- global sidebar vs block sidebar
- the typography panel of the root block in the global sidebar
- the color panel of the paragraph block in the block sidebar
- etc
I'm not particularly attached to the root name. Happy to hear options. site could work, although it has different connotations to me (your whole site opposed to a particular "block").
|
I echo the concern about naming. I have no idea what is the difference between |
If we take CSS as analogy, The difference is the difference between the |
|
I tried to read through the conversations between What the style system describes can be reduced to: block attributes, variable styles, settings. These are always attached to a root. By default, that root is the site, so "site" is always the implicit key of the theme.json object. Further down the tree, each template part (or perhaps each semantic template part) can be a more specific provider. I feel I'm missing something in this representation :) |
|
Thinking on this, perhaps |
oandregal
changed the title
|
I think it'd be beneficial to explain a bit more the rationale to split "root" and "defaults". The first thing to note is that defaults don't have block styles, defaults only have settings. The second point is that by splitting them, we make a couple of use cases a lot easier to implement via theme.json:
For example, how would we implement "only enable link color for the root block". Before this change, we need to set that in every block: With this change, we only need to set defaults and root: |
|
I do like |
|
@carolinan @gziolo @mtias Does the current setup address your concerns? I think Ari's comment summed up the situation nicely. In short:
Ideally, we'll merge this PR before the end of the day (in ~5h), so it can be part of 9.9 (so we batch all theme.json changes in one release). Potentially also of WordPress 5.7 if the other things are ready #27506 |
|
I'm fine with whatever is easier to follow for theme developers 😃 It definitely it's better now! |
|
I prefer default over *. |
|
I see now where the difference is coming from. For me the { // implicit site root
"styles": {},
"settings": {},
"blocks": {}
}Because I think of every global styles object as something that defines a styling context and is composable. In this example site = index = root, since I guess we'd want the flexibility of specifying different settings for something like a page template vs the main index template: // :root = body
"site": {
"styles": {},
"settings": {},
"blocks": {}
}
// :root = body.page
"page": {
...site /* inherits the configuration of the site and overrides specific parts */
"styles": {},
"settings": {},
"blocks": {}
}
// :root = .template-part-header
"template-header": {
... // inherits from whatever main template contains it
"styles": {},
"settings": {},
"blocks": {}
}One scenario the above doesn't cover is a different configuration for "template-header" if it's used in "page" vs when it's used in "index", but I'm sure we can find a way to express that ("index:template-heder" and "page:template-header"). Or we might prefer to always declare sub-contexts within the "blocks" object as just "core/template-part". That's more of a detail. I haven't been using the latest iterations in depth on a theme, so take my feedback as just my impression on the overall appearance of the system. |
|
I just commented with Matías what he shared. There're some ideas there that we need to explore deeper as per #20331 In particular, how to express nested contexts and different templates. That topic can change our vision on how to use theme.json as the need to include other theme metadata already has. Hence, it seems premature to land this format in core for 5.7. So, this is what I'd like to do: merge this PR in Gutenberg 9.9 and continue iterating on the plugin. |
This PR continues the work started at #28110 to update the shape of theme.json according to #28163 It splits the existing
globalblock selector in two:root=> to address the site rootdefaults=> to address all blocks at onceBefore this change, the settings under the
globalblock selector would have two functions: serve as default values for the other blocks and actually set the "global" block:After this change, the default values should be declared under the
defaultsblock selector and therootonly contains settings & styles for the block that represents the root of the site:See updated documentation for more details.
How to test