-
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
FSE: Group block: Pass "inherit layout" to child blocks #29983
Comments
I kind of disagree with this. When you define the layout to a container block, the alignments definition should be limited to its direct children, not its grand children.
Both these options break in a lot of situations, because if I use a group block in a sidebar, or a footer, or a column or anything that is not the "root" container, it breaks. -- One possibility could be to auto inherit the default layout if the container is in the root of the template, but this also breaks in some situations: a header can be at the root level but you want its content to not have any "content size" and just be full width by default. |
Could we just have this behaviour for group blocks inside the post content block? |
This also can break in a lot of ways:
Also, by default the "group" block is just placed like any other block, this means if it's container (post content here) has a layout defined, it will be "centered", meaning if we want to apply the same layout as the container, it probably needs to be inserted as "full width" by default if the parent has a defined layout. I can understand the reasoning for wanting that behavior but for me, it's way too complex to be worth it. The simplest thing is often the best solution for me. That said, I do believe that are some flows that need improvement, for instance "transforms" or "grouping" actions. Ideally these actions could be smart enough and do this:
The other thing that would be good to implement IMO is about "moving blocks": For me moving blocks from one container to another should reset the "align" attribute of all these blocks if the two container blocks have a divergent "layout" config. |
For non-block themes, a full-width group block with a paragraph inside of it looks like this: ... but by default, it looks like this in a block-based theme: That seems like it's going to be confusing for users. Plus, I'm positive that folks have existing content that relies on the current way of doing things. So changing this default makes me weary. I had some related, higher-level thoughts over in WordPress/theme-experiments#233, but I'm definitely still thinking through it all — this is a really complicated problem. 😅 |
Why do you think it's confusing, for me it's just the normal behavior of divs in HTML, so it's less likely to confuse anyone unless you define some content widths for your group block? |
I think that's it actually — while that's maybe intuitive for folks who know HTML, most of our user's don't necessarily have knowledge of how
|
I think there's something missing in the discussion here. The important thing about the site editor is that you can start blank and build your site/template step by step. So for me, as a user, I wouldn't understand why when I add a block, it goes centered by default, what does the space around the block correspond to? it's not defined anywhere and everything should be declarative. This means if I want my content to be centered, I know that I have to insert some container and define its layout. Now for baseline FSE users, these are first theme authors, they build the initial templates so they know that inserting something should take all the space by default (regardless of whether it's HTML or not). I wonder how much of the thinking here is influenced by how the post editor works. Now, I agree that it's not perfect, what I don't like personally is that fact that the default layout is applied to the post editor automatically instead of being inherited from the "parent template" of the current post being edited. This is though very hard to do automatically, we'd have to try to load the template of the current post, parse it, understand where the content falls and check the layout of its container. It's too complex and probably a bit fragile to implement so that's why I think the "layout" config automatically applied to post editor is good middle ground for the post editor. |
as a user, I wouldn't understand why when I add a block, it goes centered by default, what does the space around the block correspond to? They expect it because it has been the default in the post editor. It is the sudden change that is unexpected and difficult to understand. It is not a seamless transition when you switch editors, and it needs to be. |
Another possible approach here which would be useful would be that if I declare "inherit layout" on a parent block and a child block, the child inherits the layout from the parent so that I can have multiple blocks in the stack using the same alignment rules. |
I think it's worth reviving this discussion in the context of the Query block, where it sounds like we're likely to have two nested levels of container blocks (Query + Query Loop), each with their own Layout controls. Some things I'd be open to exploring:
These may not work in practice, but would be worth trying out. This nesting issue would also be a good thing to consider in tandem with the UI + labeling explorations happening in #31950. |
I think this is a good solution to this problem: #33501 |
What problem does this address?
The previous way that themes styled group blocks was that all group blocks would inherit the default layout. Since #29335 this can now be achieved by setting "Inherit default layout" on the group block.
What is your proposed solution?
If a group block opts in to "Inherit default layout", users would probably expect this behaviour to be inherited by children of that block.
Another option is to have all group block enable "Inherit default layout" by default.
A third option is to make it possible to opt in to this rule in theme.json.
cc @youknowriad
The text was updated successfully, but these errors were encountered: