Try: Restore block mover for floats. #12758
Conversation
jasmussen
force-pushed
the
try/float-mover-fix
branch
from
7a513cc
to
038de36
Compare
| { isFirstMultiSelected && ( | ||
| <BlockMultiControls rootClientId={ rootClientId } /> | ||
| ) } | ||
| <div className="editor-block-list__block-edit"> | ||
| { shouldRenderMovers && ( |
There was a problem hiding this comment.
For the block mover to be able to work for a right-floated block, it has to be inside .editor-block-list__block-edit, or the control will show up way on the left of the main column. Same case as when we refactored the floats, essentially.
jasmussen
force-pushed
the
try/float-mover-fix
branch
from
038de36
to
f4cccf8
Compare
| @@ -1,8 +1,8 @@ | |||
| .editor-block-list__layout .components-draggable__clone { | |||
| // Hide the Block UI when dragging the block | |||
| // This ensures the page scroll properly (no sticky elements) | |||
| // Hide the Block UI when dragging the block. | |||
There was a problem hiding this comment.
Just a few comment cleanups while I'm in here.
|
I think the iteration could happen in a separate PR but I think this is another case where some version of #7211 would help with the mover overlap issues. |
I know I've been skeptical in the past, but I'm starting to agree especially for nested blocks and now floats. I still don't really see the value it brings to top level blocks, except perhaps the consistency it would bring, but for those blocks which for now are still the most common, the extra chrome behind the controls just seems heavier. |
|
@jasmussen Yeah it's primarily a consistency thing, although I do think it will be more practically valuable as the editor starts to reflect the front-end more and more and the "base level" editor canvas isn't so bare. But that could be a future iteration; it could definitely focus just on InnerBlocks for the moment. |
|
@youknowriad For now I've set this in "future/phase 2". But I would appreciate a pair of eyes if you have time — could we get this into a plugin release like 4.9? I'd love for it to land early between major releases. |
|
I've put this PR in 4.9 to get some review 👀 It doesn't mean it's going to ship there though. Depends on the reviews. |
|
I'm not necessarily super antsy that it land in 4.9 or even 5.0, but I appreciate it being on the radar! Thanks Riad! 💕 |
| .editor-block-contextual-toolbar { | ||
| // I think important is fine here to avoid over complexing the selector | ||
| // I think important is fine here to avoid over complexing the selector. |
There was a problem hiding this comment.
| // I think important is fine here to avoid over complexing the selector. | |
| // I think important is fine here to avoid over-complicating the selector. |
| @@ -168,7 +168,7 @@ | |||
| background-color: $blue-medium-highlight; | |||
| } | |||
|
|
|||
| // selection style for multiple blocks | |||
| // Selection style for multiple blocks. | |||
| &.is-multi-selected *::selection { | |||
There was a problem hiding this comment.
| &.is-multi-selected *::selection { | |
| &.is-multi-selected ::selection { |
I think that asterisk is redundant.
There was a problem hiding this comment.
Good thought, but I'd prefer not actually making this change in this PR. It is already sort of big surgery and I'd like to minimize the changes as much as possible. Given that code did not change in this PR, only the comment, I'd prefer to look at this separately.
jasmussen
force-pushed
the
try/float-mover-fix
branch
from
f4cccf8
to
bd963c4
Compare
|
Rebased, and addressed feedback. Tested again. I think this is good to go, it seems to work well for me. It would be good to get in after 5.1, but before 5.2, so I think now might be a good time to merge this. One thing I fixed was hiding the block mover from the gray ghost when dragging:
|
|
Merged 🎉 |
|
|
* Try: Restore block mover for floats. This PR hopes to fix #12736, #11424, #10300. Currently we hide the block mover for any floated block. We do this because if you have a left floated image followed by a paragraph, the block mover for the image would overlap exactly with the block mover for the subsequent paragraph block. This would cause moving a float to be fiddly and virtually impossible as the hover states for the two conflicted. This PR is an experiment to mitigate, or possibly fix that. It's a try branch because it is not necessarily a solid fix. What this PR does: - It makes it so the block mover cannot be invoked when only hovering a float, but when the float is selected they are permanently visible. - It changes some z-indexes so floats always have a higher z-index than not a float. - It changes the footprint of the side-UI container to "cover up" the underlying paragraph block, so it won't invoke unlesss you move the mouse below the footprint. This is best explained in some GIFs. The reason this is a "Try" branch is that when you move the mouse over the adjacent paragraph, the block mover is show as overlapping the selected floats block mover. But due to the rearranging of z-indexes, at least this is only a visual issue. A click on the floats block mover will still work as intended. Why can't the float have on-hover block movers like every other block, you ask? Picture again the test-case of a left floated image followed by a paragraph of text. In this case, hovering over the image would show a block mover that would visually appear to be that of the paragraph block. By showing it when the float is selected, the context is clear. We could experiment with not showing the hover block mover for float-adjacent blocks when hovered, but this isn't feasible because you might have a float, and then a block that clears this float, in which case the rule would break down. Lay your thoughts on me. * Address feedback, and improve dragging edgecase. This addresses comment feedback by @ZebulanStanphill, thanks, and it also hides the block mover from the ghost when you are dragging. * Add borders around floats.
* Try: Restore block mover for floats. This PR hopes to fix #12736, #11424, #10300. Currently we hide the block mover for any floated block. We do this because if you have a left floated image followed by a paragraph, the block mover for the image would overlap exactly with the block mover for the subsequent paragraph block. This would cause moving a float to be fiddly and virtually impossible as the hover states for the two conflicted. This PR is an experiment to mitigate, or possibly fix that. It's a try branch because it is not necessarily a solid fix. What this PR does: - It makes it so the block mover cannot be invoked when only hovering a float, but when the float is selected they are permanently visible. - It changes some z-indexes so floats always have a higher z-index than not a float. - It changes the footprint of the side-UI container to "cover up" the underlying paragraph block, so it won't invoke unlesss you move the mouse below the footprint. This is best explained in some GIFs. The reason this is a "Try" branch is that when you move the mouse over the adjacent paragraph, the block mover is show as overlapping the selected floats block mover. But due to the rearranging of z-indexes, at least this is only a visual issue. A click on the floats block mover will still work as intended. Why can't the float have on-hover block movers like every other block, you ask? Picture again the test-case of a left floated image followed by a paragraph of text. In this case, hovering over the image would show a block mover that would visually appear to be that of the paragraph block. By showing it when the float is selected, the context is clear. We could experiment with not showing the hover block mover for float-adjacent blocks when hovered, but this isn't feasible because you might have a float, and then a block that clears this float, in which case the rule would break down. Lay your thoughts on me. * Address feedback, and improve dragging edgecase. This addresses comment feedback by @ZebulanStanphill, thanks, and it also hides the block mover from the ghost when you are dragging. * Add borders around floats.
This PR hopes to fix #12736, #11424, #10300.
Currently we hide the block mover for any floated block. We do this because if you have a left floated image followed by a paragraph, the block mover for the image would overlap exactly with the block mover for the subsequent paragraph block. This would cause moving a float to be fiddly and virtually impossible as the hover states for the two conflicted.
This PR is an experiment to mitigate, or possibly fix that. It's a try branch because it is not necessarily a solid fix. What this PR does:
This is best explained in some GIFs. Here's one where the block mover footprint is coral colored to help explain what's going on:
Here's without that coral debug color:
The reason this is a "Try" branch is that when you move the mouse over the adjacent paragraph, the block mover is show as overlapping the selected floats block mover. But due to the rearranging of z-indexes, at least this is only a visual issue. A click on the floats block mover will still work as intended.
Why can't the float have on-hover block movers like every other block, you ask? Picture again the test-case of a left floated image followed by a paragraph of text. In this case, hovering over the image would show a block mover that would visually appear to be that of the paragraph block. By showing it when the float is selected, the context is clear.
We could experiment with not showing the hover block mover for float-adjacent blocks when hovered, but this isn't feasible because you might have a float, and then a block that clears this float, in which case the rule would break down.
Lay your thoughts on me.