What problem does this address?
In block themes, where each container block must specify its content width, Cover block has no settings to do so. This causes issues such as #37036.
An initial attempt to add Layout support to Cover (#37662) ran into trouble because of the complex markup structure of the block. The problem is similar to the Navigation block, which was addressed with a custom solution in #37473.
Additionally, the Cover block has a unique "Change content position" control in its toolbar, that allows aligning the content on a two dimensional axis that uses flexbox under the hood. If we migrate Cover to use Layout, it makes sense to replace this with the existing flex layout type.
What is your proposed solution?
We could use the same custom solution as for Navigation block. That would work well for the flex layout scenario, but we'd also like Cover to work with the default (or content width enabled) layout, and that might be problematic because the max-width values we need for content width can't be hardcoded into the block stylesheet.
(As an aside, we'll need to dust off the Layout type switcher that currently isn't in use anywhere). Design might be needed because we haven't looked at it in a while 😄
Ideally, we'd have a way to add the layout classes to the inner block wrapper (as mentioned on the original PR), so the layout styles would always work flawlessly, independent of block markup structure.
If #42485 goes forward, we could leverage a brand new Walker to do this, or we could modify the existing logic slightly, but either way it looks like we'll need some classname or other way to identify the inner block wrapper. Should we use a classname, do we want to output it in the front end? Or just use it as a temporary internal hook to identify inner block containers? What other uses could such a thing have? (I'm thinking it should be added to all inner block containers, so we can be consistent with the layout logic.)
Any further ideas and feedback welcome!
What problem does this address?
In block themes, where each container block must specify its content width, Cover block has no settings to do so. This causes issues such as #37036.
An initial attempt to add Layout support to Cover (#37662) ran into trouble because of the complex markup structure of the block. The problem is similar to the Navigation block, which was addressed with a custom solution in #37473.
Additionally, the Cover block has a unique "Change content position" control in its toolbar, that allows aligning the content on a two dimensional axis that uses flexbox under the hood. If we migrate Cover to use Layout, it makes sense to replace this with the existing
flexlayout type.What is your proposed solution?
We could use the same custom solution as for Navigation block. That would work well for the flex layout scenario, but we'd also like Cover to work with the default (or content width enabled) layout, and that might be problematic because the max-width values we need for content width can't be hardcoded into the block stylesheet.
(As an aside, we'll need to dust off the Layout type switcher that currently isn't in use anywhere). Design might be needed because we haven't looked at it in a while 😄
Ideally, we'd have a way to add the layout classes to the inner block wrapper (as mentioned on the original PR), so the layout styles would always work flawlessly, independent of block markup structure.
If #42485 goes forward, we could leverage a brand new Walker to do this, or we could modify the existing logic slightly, but either way it looks like we'll need some classname or other way to identify the inner block wrapper. Should we use a classname, do we want to output it in the front end? Or just use it as a temporary internal hook to identify inner block containers? What other uses could such a thing have? (I'm thinking it should be added to all inner block containers, so we can be consistent with the layout logic.)
Any further ideas and feedback welcome!