fix: unset max-width for reusable blocks #22632
Conversation
|
Size Change: +23 B (0%) Total Size: 1.12 MB
ℹ️ View Unchanged
|
|
Fast work, thank you for exploring in a PR! When a theme does not supply an editor style, what you intended is what I see:
On its own, I don't think this is terrible as it does fix the issue of allowing full-wide images inside. However this PR also highlights an issue we have not thought about — editor styles. This is what I see in the theme I'm working on:
That is — it's not full-wide, because my theme overrides that: the rules you wrote don't have enough specificity:
It would be easy to increase that specificity to force it to work. But that would actually break my theme's editor style. Which is okay if we're sure about it, but it does raise the question: are we sure about it? It touches again on #20650 specifically (CC: @youknowriad and @kjellr ) — how should a full-wide group block treat child blocks? Should child blocks be in a thin column just like they are in the root container? Or should child blocks be allowed to go full-wide because a group is just a thin wrapper? The thing that makes this extra complex is that reusable blocks are only surfaced in the editor. Which means if they inherit editor styles, they will likely cause inconsistencies. So we arguably need a way to treat reusable blocks in a way that would be consistent with how an editor style might treat it. Which is difficult — because on the front-end/published side, the reusable block is not in a wrapper, it's transparent. We effectively need for the reusable block wrapper to be as invisible and transparent in the editor as possible. Something like Adding a design feedback label to gather more thoughts, and thanks again for the PR, it's a great way to force the conversation! |
I'm not sure about it! 😄 I'd love to solve this in a way that avoids breakage — ideally themes wouldn't have to make any change to make this work right. One thought is that we could we do something like we do for the Group block? For that block, when you "group" a full-wide block, it makes the Group full-wide by default. That would mean we'd need to add alignment controls on the reusable block, which is weird... and it would likely still require some level of editor style updates for themes. 🤔 On second thought, probably not a great idea.
In normal cases, I'm still a solid no: Full-wide blocks should not go full-width if they're inside of a smaller container. I think of parent blocks like physical boxes: If you put something huge in a box, it's going to have to shrink down to fit. But I think the case of reusable blocks, it's a little different — the reusable wrapper is meant to be truly invisible. So I think we could treat that a little differently if we needed to. |
This seems to be key. Reusable blocks should ideally be a transparent editor-only affordance.
Wouldn't that require a theme to be aware of it? The thing is — you can make a single paragraph, ungrouped, into a reusable block. This wraps it in a div, and it's that div which causes all the trouble. If all reusable blocks were by definition turned into groups first, then we could potentially level the playing field by targetting the group styles in a generic way. But alas, I can think of a few good use cases for not grouping content just by making it reusable.
Just to be sure I explained myself: if the group is fullwide, what should happen to a not-full-wide block inside? Should it expand to fit the available space (Figma behavior) or should it act just like it does in the root container, and be in a centered column? I know we've had this discussion before, and I don't necessarily mean to up-end it — strong theme folks like yourself should have the say here. I'm bringing it up because I believe #20650 means to take the vinegar out of wide, fullwide and normal blocks by handling it, so that we could apply a class to any container and make it behave like the |
Yeah, I don't think my thoughts there make sense. 😄
I still think the Figma-like behavior is what's expected. Unless the container is meant to be 100% invisible to the user, like the special case we're talking about here. |
Can this be done programmatically? So if the inner block has a |
skorasaurus
added
the
CSS Styling
Description
This PR addresses the issue described in #8288.
See: #8288 (comment)
There are also other interesting ideas as to how we can improve this fix in the future, which can be addressed in a future PR.
If you all think this css should be more closely coupled with the reusable block (say in
packages/block-library/src/block/editor.scss, for example) let me know and I'll move it there.How has this been tested?
Unable to get
wp-envrunning on my linux machine, so this was not tested here. But I did test this in another installation by applying a similar change to the css.Screenshots
(from the issue thread)...
Types of changes
Bug fix (non-breaking change which fixes an issue)
Checklist: