Gutenberg: Floated blocks cause visual overlay issues

[karmatosed]

If you float a block the adding and suggested blocks doesn't always clear:

If you align to the right you get the suggested blocks vanishing:

This can even cause z-index issues like this:

I think if it's aligning we maybe need to not have suggested blocks, but open other ideas.

[talldan]

I've had a quick look into this issue and the related issues. It's best illustrated by an image floated either left or right with paragraph text flowing around it. In this case both the image and the next paragraph blocks have overlapping controls:

My first thought was that the UI for the blocks could appear in columns, a bit like this:

Unfortunately, the paragraph blocks have no way of knowing that they're flowing alongside a floated element, so it's hard to do anything clever with the way they're displayed. The only solutions I can come up with to determine whether a paragraph is flowing around a floated element are not particularly nice solutions.

Because of that, I think any design solution might have to focus on changing the way the UI for the floated element appears - i.e. moving it so that it doesn't overlap.

[karmatosed]

Because of that, I think any design solution might have to focus on changing the way the UI for the floated element appears - i.e. moving it so that it doesn't overlap.

Do you have an idea of what that could look like? Just as a rough concept?

[talldan]

The main issue is with the controls at the sides of blocks (block settings ellipsis icon and block mover icons), since they overlap when you have two blocks side by side and they're quite important.

The easiest thing I can come up with (without being too drastic) is to make sure they don't overlap for floated elements by making them inset. Here's a really crude example:

I don't completely like that solution - for a start the image block doesn't seem like the first block on the page because the mover icons are visually to the right of the paragraph's mover icons. But it probably is an improvement at least.

As a side note - there are a couple of technical things that could be improved around floated blocks:

• left and right floated blocks are a div with a floated div inside it. At the moment the height of the outer div collapses to zero, which causes a bunch of issues. I think the outer div should be the one with the float applied.
• There are z-index issues. Floated blocks aren't always on top of neighbouring full-width blocks in terms of z-index, making them hard to select.

[designsimply]

Closed https://github.com/WordPress/gutenberg/issues/7848 as a duplicate.

[karmatosed]

Noting this isn't just the image block: https://github.com/WordPress/gutenberg/issues/6288

[karmatosed]

Another one to consider in this is what happens on the bottom with overlaps and lack of clearing: https://github.com/WordPress/gutenberg/issues/6490

[ZebulanStanphill]

@talldan Would #6224 help with the controls-overlaying issue?

[talldan]

@SuperGeniusZeb - I quite like the redesign in #6224, but not sure it solves the issue, unless the controls were only visible when the block is selected and they were made to sit over the top of the floated element. Here's a quick sketch showing how things would overlap:

One other side effect of the block controls being at the bottom is that you end up with bigger gaps between paragraphs.

[ZebulanStanphill]

@talldan The block controls would not take up space on hover (just like they and the block toolbar do not take up space now), and as far as I can tell it is not even decided yet if they would take up space on a selected block. And of course, the controls would only be shown for blocks that are either selected or being hovered over. The standard distance between blocks should be unaffected by the change; only the selected block may be affected.

[talldan]

@SuperGeniusZeb that makes sense. I don't think it solves this issue, which is a shame :(

[karmatosed]

I think we should get a fix here without #6224 or at least not being dependent on that issue. We would need to extensively usability testing any block control change that major before bringing in. As a result we need a fix here over thinking that would be it.

[designsimply]

Closed #8355 to consolidate here because it's a concern about how to move floated blocks and the z-index issues mentioned here are closely related. Note that the concern in #8355 is more specifically about how to grab a floated block with the mouse and drag it to another location within the document.

[mtias]

@karmatosed @jasmussen what is the status of this one?

[jasmussen]

Closing this one as fixed:

It's not yet a perfect experience, but it's better to close this one and either reopen or revisit if/when the issue surfaces again.

[omrllm]

In some articles the plugins floats on top of the editor block itself, like with the image problem here.
The image is taken on mobile.

[jasmussen]

@omrllm The issue you appear to be seeing looks a lot like the browser is running in "Quirks Mode", which means it is rendering in compatibility mode. That suggests a plugin is at fault. More info in https://github.com/WordPress/gutenberg/pull/12575.

Can you try and deactivate plugins one by one to see if it starts working? I believe Yoast SEO should _work_, so maybe deactivate that one last to see if it's one of the others causing the issue.

Let us know if a plugin is at fault, and which one it is, then I can reach out to the developer and suggest fixes.

[omrllm]

Alright, it's WD YouTube by WebDorado.
Once deactivated that problem doesn't appear anymore.

[jasmussen]

Thanks so much @omrllm, I can confirm that I can reproduce it with that plugin also. It's because it outputs a JavaScript tag before the doctype, causing the editor to render in quirks mode:

I'll reach out to them and suggest a fix. Thanks!

[omrllm]

Happy to help :+1:

I'll reach out to them and suggest a fix.

Sweet :smiley: