kadence-blocks icon indicating copy to clipboard operation
kadence-blocks copied to clipboard

Handle Row Layout background content as InnerBlocks

Open rchipka opened this issue 6 years ago • 4 comments

In order to provide the most flexibility when it comes to controlling the background of Row Layout blocks, we should probably handle this as a toggleable foreground/background editing mode.

This would also save us from having to reinvent the wheel. For instance, all of the options available in the Row Layout's background settings can be recreated as a Cover Image block.

If we handled both background and foreground Row Layout content as InnerBlocks, then users would be able to add things like video embeds as section backgrounds without Kadence having to keep up with every imaginable need for background options.

Perhaps this could be a toggle in the Block Toolbar after the Row Layout width/alignment settings. Toggling the button would simply change the display property of the foreground block layout wrapper and the pointer-events property of the background block layout wrapper (from "none" to "all").

The output CSS would simply set the z-index of the background layout wrapper to "-1", while positioning the background layer as absolute with 100% height so that the background wrapper is limited by the statically positioned foreground/container height.

rchipka avatar Jan 28 '19 22:01 rchipka

This would also ideally be backwards compatible with the existing Row Layout block.

Perhaps it could be handled as a separate Row Background block, which is only available as a direct child of a Row Layout.

This block would be accounted for as a special case in the styling, allowing it to break out of the flexbox layout as an absolutely positioned full-width/height element.

rchipka avatar Jan 28 '19 22:01 rchipka

Hey, I'm not sure it's possible to do this and maintain backward compatibility or frankly even possible simply due to limitations. For example, you can only have one InnerBlocks component per block.

There are tons of issues I can think of that would create way more problems with both styling and usability.

For example, if someone put a video block in the background section that video isn't going to "cover" and if you simply force absolute 100% with css it would stretch the video awkwardly. Background video can't simply be replaced by a video block. And with most blocks not being designed to function as a background I just see that as ending poorly.

Perhaps I am just not understanding what you want.

kadencewp avatar Jan 28 '19 23:01 kadencewp

@kadencethemes You're correct about the InnerBlocks limitation, but I believe it can be overcome by using a static/locked InnerBlocks template with two hidden block types.

That's a good point that not all blocks are prepared to handle being set as a background.

In my mind, the usual "fixed", "cover", and "contain" functionalities could be emulated with the correct overflow, position, and min-height settings on the child background wrapper.

There would still be a use case for having a built-in overlay setting, should a user want an overlay on a block that doesn't provide it, which would make any block able to function as a eye-pleasing background.

All in all, I agree that there are plenty of edge cases as well as technical challenges and limitations.

That, and possibly breaking backwards compatibility are probably good reasons not to do it.

My main thinking is to avoid the onslaught of options and settings needed to handle lots of background edge cases.

Like what about options for images at certain crop sizes, hover animations, or, if it supports video, autoplay/muted settings?

And that's just examples of settings, but people might want all kinds of variations on backgrounds.

For instance, someone might want to make the "Image Gallery" block into the background for a section, or even a "Google Maps" block, or some custom block that does scrolling post thumbnails (like client logos, etc).

In some of these cases, you could argue that users should just make the background a static image (or video), and I could easily argue in either direction, but the idea behind this feature (if possible) would be to provide more flexibility/ease-of-use.

rchipka avatar Jan 29 '19 01:01 rchipka

It's an interesting Idea. I'm not sure I see it but I will look into it. I can see adding video without much trouble and with a much better implementation then any video block would be able to provide. I can see adding responsive options for image position also without much trouble.

For the edge cases, it's hard to justify all that it. I almost think it would be easier to create a single block that was a wrapper you could add after any other block and it would become the previous blocks background. still, though, I am having a hard time seeing it as getting much use.

kadencewp avatar Jan 29 '19 05:01 kadencewp