-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Move block css from supports > __experimentalStyle to a top level style key in block.json #41873
Conversation
5d41863
to
b0ae335
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Lots of failing tests. Worth a rebase. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like there are now other core blocks that use supports.__experimentalStyle
and they should get refactored as part of this PR:
- Audio
- Embed
- Image
- Navigation
- Table
- Video
This is a valid concern because of JSON schema for Related code: gutenberg/schemas/json/block.json Lines 458 to 485 in 1a33c0d
The remaining task is documentation, as it will be very important as we extend the existing API: but also: maybe it would be worth covering also in: In general, it's important to reference how styles can be represented with the same format as in |
I added a commit to fix the schema, but I'm not sure if will work, because the test references the canonical URL of that file. |
Co-authored-by: Adam Zielinski <adam@adamziel.com>
54a177f
to
99902b6
Compare
@scruffian I couldn't see that commit on the list so I added this one: 1119b4c |
@mtias brought this up:
It could look like this: "attributes": {
"style": {
"default": {
"color": {
"text": "#fff",
"background": "#32373c",
},
},
},
}, It does make sense to me. At the same time, I don't like how:
This tells me it's not like any other attribute – should we define it alongside other attributes then? I'd love to hear more opinions on this one – what do you think @gziolo, @dmsnell ? |
It never occurred to me that we could move the value stored in gutenberg/packages/block-editor/src/hooks/style.js Lines 126 to 132 in 8b9db3d
It's defined as the type My question here would be whether the values stored in Assuming that the answer is yes, the more important consideration is the practical implications of using the
It isn't impossible to make it work, but we would need to explicitly define that the default value needs to get merged with the current value of the const style = { ...blockType.attributes.style.default, ...block.attributes.style }; |
Whatever is stored in this key (whether it's __experimentalStyle, style or attributes), I don't think it should be output inline in the block. These settings can be output as CSS against the |
@scruffian changing just the padding of the <div class="wp-block-buttons"><!-- wp:button {"style":{"border":{"//":"100% causes an oval, but any explicit but really high value retains the pill shape.","radius":"9999px"},"color":{"text":"#fff","background":"#32373c"},"typography":{"fontSize":"1.125em","textDecoration":"none"},"spacing":{"padding":{"//":"The extra 2px are added to size solids the same as the outline versions.","top":"10px","right":"calc(1.333em + 2px)","bottom":"10px","left":"calc(1.333em + 2px)"}}}} -->
<div class="wp-block-button has-custom-font-size" style="font-size:1.125em;text-decoration:none"><a class="wp-block-button__link has-text-color has-background wp-element-button" style="border-radius:9999px;color:#fff;background-color:#32373c;padding-top:10px;padding-right:calc(1.333em + 2px);padding-bottom:10px;padding-left:calc(1.333em + 2px)">text</a></div> Storing just the updated values would require a new switch for
Here's another concern: Currently, the styles are determined using the following hierarchy:
Moving the styles from 2 to 5 would change that hierarchy – the block.json styles would matter more than the theme.json styles. |
Just a heads up that we have two places where we are putting these kinds of styles: block.json and core theme.json. It's essential that we are consistent with our approach. /cc @scruffian Having the ability to define the styles in block.json is good for plugin devs. Deciding to move the block styles to theme.json means that the block as a component will lack those styles, even though in general it seems more convenient to have all blocks define those styles in the same place. |
I really like @mtias proposal because I love when things just work out of the box. Sadly, if it needs a separate implementation from the rest of the attributes, it kind of undermines its purpose. From a DX point of view, if I'm not mistaken, the From an API point of view, this is quite close to the work of the descendant styles/settings (this PR and this PR from the work derived from @mtias' sections proposal). I'm worried that whenever we want to open For example, would this change the background of the block, or the background of its child blocks?: {
"styles": {
"color": {
"background": "red"
}
}
} The same problem exists if we go with I think the decision of what API to use here should be taken with that work into consideration. /cc @mcsf @jorgefilipecosta |
What if we approach this the same way we did for "style variations" in themes?
Conceptually, it's probably simpler for the block author to understand that the block CSS is moved from |
The meaning of the "default" variation isn't very clear to me. Say I switch to a theme where everything has rounded corners – it would make sense to display the image blocks using their "rounded" style variation. If we do that, however, the user will see two style variation: the selected one called "rounded" and the other one called "default". This is to say that the word "default" is contextual so using a file called This requires a separate issue and explorations, though. If I compressed this too much, @MaggieCabrera can explain it much better than I can. |
I like André's folder idea. I guess what he is proposing is to add the styles directly to the JSON itself (aren't you?): {
"color": {
"background": "red"
}
} I like that because it's very simple. But maybe we could use the
// block.json
{
"name": "core/button",
"...": "...",
"styles": {
"color": {
"text": "black",
"background": "red"
}
}
} // styles/fancy-yellow-button/block.json
{
"name": "fancy-yellow-button",
"label": "Fancy yellow button",
"styles": {
"color": {
// text remains black
"background": "yellow"
}
},
"style": "file:./fancy-yellow-button-style.css",
"viewScript": "file:./fancy-yellow-button.js",
} Actually, I've been thinking about the folders pattern for a while. Specifically, a I also had an interesting conversation with @sunyatasattva last week about their need to override some
Anyway, I wouldn't like to distract the conversation away from this PR. If the default styles definition can stay in the main @oandregal: do you see any strong reason for using |
I just read this comment from @MaggieCabrera in another issue:
I guess there's still a need for a set of default |
yes, for variations there's a few things that would be good to have:
For the second to work, we need to redefine what "default" means, since right now it means the absence of a class and its associated CSS, but if suddenly the default style variation for image is rounded, we don't have a way to reset the border radius to 0 if the user chooses to change their images. |
No, I'm not opinionated about how a block define its styles (either within My concerns about the current proposal (overloading the top-level
Additionally, we need to consider how to absorb block style variations into the merging algorithm as well. Perhaps I was too ahead of myself sharing the folders idea. I think it's promising but we should focus first on understanding how |
There is not enough alignment to merge this PR so I'm closing it. Feel free to take over! |
I have gone ahead and created an issue to track the next steps for this experimental API #45198 |
What problem does this PR solve?
In #34180 we moved block CSS to
blockJson.supports.__experimentalStyle
. This PR moves it underblockJson.style
at the root level. The goal is to only have a single location where styles are defined.See WordPress/wordpress-develop#2853 for more context
cc @getdave @scruffian @draganescu