Skip to content
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

Closed
scruffian opened this issue Mar 18, 2021 · 11 comments
Closed

FSE: Group block: Pass "inherit layout" to child blocks #29983

scruffian opened this issue Mar 18, 2021 · 11 comments
Labels
[Block] Group Affects the Group Block

Comments

@scruffian
Copy link
Contributor

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

@youknowriad
Copy link
Contributor

If a group block opts in to "Inherit default layout", users would probably expect this behaviour to be inherited by children of that block.

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.

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.

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.

--
That said, we can introduce some smart behavior maybe, but the heuristics are very hard to get right that's why I preferred explicitness for now.

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.

@scruffian
Copy link
Contributor Author

Could we just have this behaviour for group blocks inside the post content block?

@youknowriad
Copy link
Contributor

Could we just have this behaviour for group blocks inside the post content block?

This also can break in a lot of ways:

  • You add a padding or margin to the group block, the widths are not correct anymore
  • You add a background (auto-padding) it breaks

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:

  • if the parent of the selected blocks has a layout and one of the selected blocks is wide or full "aligned", insert a "full width" group instead of a regular group and inherit the layout.

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.

@kjellr
Copy link
Contributor

kjellr commented Mar 19, 2021

For non-block themes, a full-width group block with a paragraph inside of it looks like this:

Screen Shot 2021-03-19 at 2 57 16 PM

... but by default, it looks like this in a block-based theme:

Screen Shot 2021-03-19 at 2 59 34 PM

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. 😅

@youknowriad
Copy link
Contributor

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.

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?

@kjellr
Copy link
Contributor

kjellr commented Mar 22, 2021

for me it's just the normal behavior of divs in HTML

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 p or div tags behave out of the box.

p tags don't have a max width in HTML by default, but we imposed one in the post/page editor default styles because it's a a better experience for readability, and because it makes wide/full widths possible. Our baseline FSE users are used to that by now, and I worry they won't understand why things are working differently in that context — there are already a lot of new things to learn in that interface.

@youknowriad
Copy link
Contributor

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.

@carolinan
Copy link
Contributor

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.
-And if themes can include HTML templates in a classic PHP based themes, the behaviors in the site editor and post editor needs to match.
I already find it difficult not being able to adjust the width of the "root" block in the site editor, when I can do that in the post editor; and that is because even though I know why, users have habits.

@scruffian
Copy link
Contributor Author

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.

@kjellr
Copy link
Contributor

kjellr commented May 20, 2021

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:

  • Adding a setting for children with layout controls to mirror the layout settings of their parent (I think this is what @scruffian proposed above). If I've set the Query block content column to be 50% wide, then I should have a setting in the Query Loop block to use that same setting without manually entering it again.
  • Allowing certain containers to be "pass through" blocks in terms of layout. For example, maybe the Query Loop doesn't have any layout settings of its own, and its children use the layout settings set in the Query block.

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.

@scruffian
Copy link
Contributor Author

I think this is a good solution to this problem: #33501

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Group Affects the Group Block
Projects
None yet
Development

No branches or pull requests

5 participants