Align image left/right - drag handle visibility issues. #11424
Labels
General Interface
Parts of the UI which don't fall neatly under other labels.
[Type] Enhancement
A suggestion for improvement.
Comments
paaljoachim
changed the title
|
Tested and confirmed using WordPress 4.9.8 and Gutenberg 4.2.0-rc.1 that when an image is left-aligned the drag handles appear on the right and bottom and when an image is right-aligned the drag handles appear on the left and bottom and when an image is centered the drag handles appear on the left, right, and bottom. I had assumed this was by design and not a mistake though. |
designsimply
added
Needs Design Feedback
|
I looked through this again. Here is a gif I made to show when the drag handles show up.
|
paaljoachim
changed the title
|
Movers and drag handle are not visible in floated blocks by design. It's not ideal but there's no better alternative at the moment. I'm inclined to close this issue at the moment. Not sure if there are plans to revisit this at the moment cc @jasmussen |
|
Example of showing block outline at current: Suggestion of including mover and drag handles at default without having to hover the left side of the block: |
This is correct. As you show yourself in #11424 (comment), if the movers & drag handle showed up to the left of a left floated block, it would overlap the block beneath it, and I'm concernd that #11468 is too complex of a solution for that problem. To be clear: yes, we want movers for left and right aligned content. But Riad is also correct that they are disabled for now, because it didn't work when we had them there. Our current best plan is to show the same layout for a floated block, as we do for blocks on mobile — that is, below the block. But in absence of pull requests making this happen in the next few days, it's likely the movers won't return for floated content until the next WordPress release. |
|
Ok. I am thinking we will just let another solution show it self over time. Thanks for the comment. |
designsimply
added
[Type] Enhancement
|
Closing for now and noting that #11454 was added to the Ideas project which is a place to add issues for later consideration. |
jasmussen
pushed a commit
that referenced
this issue
Dec 10, 2018
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.
jasmussen
pushed a commit
that referenced
this issue
Jan 30, 2019
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.
jasmussen
pushed a commit
that referenced
this issue
Feb 5, 2019
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.
gziolo
pushed a commit
that referenced
this issue
Feb 6, 2019
* 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.
youknowriad
pushed a commit
that referenced
this issue
Mar 6, 2019
* 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.
youknowriad
pushed a commit
that referenced
this issue
Mar 6, 2019
* 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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Aligning image left the drag handle dissapears
To Reproduce
Steps to reproduce the behavior:
Expected behavior
To see the drag handles on all alignment options left/center/right.
Screenshots
Desktop (please complete the following information):
The text was updated successfully, but these errors were encountered: