Grid: Drag handles can become quite unintuitive and lead to unexpected results

[ndiego]

Description

The best way to explain this bug is with a video, which you will find below. Basically, as you start playing around with the drag handles on a block contained within a Grid variation, the Row Span and Column Span values can get out of sync with what you actually see in the Editor canvas. This can become confusing, especially if you do not understand how grid works in CSS.

I'm labeling this as a bug because I think there are some fairly significant usability issues here.

Step-by-step reproduction instructions

1. Use WordPress 6.6.
2. Add a Grid block and place some blocks inside it
3. Mess around with the drag handles, like in the video

Screenshots, screen recording, code snippet

grid-drag-handles.mp4

Environment info

• WordPress 6.6
• Same issues occur in Gutenberg trunk

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[annezazu]

Great feedback. I just messed around with Grid more and can replicate the same strangeness. Tagging in @WordPress/gutenberg-design to explore this further.

[tellthemachines]

@ndiego what did you expect would happen when you first dragged the resize handle upwards on that 2x2 span block? I'm thinking it would be one of two things (please correct me if I'm wrong!)

• the block resizes upwards by one row, partially overlapping the two blocks above. That's what we're implementing in the new manual mode, just merged in Grid interactivity: Allow blocks to be positioned in manual mode using drag and drop #61025 behind an experiment flag (if you could give that a spin and provide feedback it would be very welcome!)
• the block resizes downwards by one row, not overlapping the blocks above. This is trickier because it would require adding a minimum height to rows that don't otherwise have any content to define their height. I tried that in Use grid-auto-rows to ensure min height of new grid rows. #61383 but the consensus was that it's preferable to not do it.

[jasmussen]

Good issue, good discussion. The core of the issue really is that CSS grid itself, is pretty complicated. I completely agree with the statement that it feels unintuitive; you've got 4 rows, and when resizing a cell to fit 3 rows, you'd presumably expect it to fit three cells. Either through:

• The other images resizing themselves to allow the resize to fit 3 rows.
• Or overlap, happening.

I suspect this grid is in "auto" mode, whereas probably "manual" would've been a better experience in this case. I wonder if a couple of things we can try is:

1. Make manual default.
2. Don't show resize handles in auto mode at all.

2 does sound a bit controversial, but the question is: what's the value of being able to resize in the canvas in auto mode if the results can be entirely unpredictable? When you resize upwards in the canvas but either nothing happens or it adds additional rows below, what you get is not what your drag action suggested. Could we hide more handles in auto mode, if not all? Mainly, manually adding the numberes in the inspector may ultimately be a better experience in that case.

As a sidenote, there are many aspects of grid, not yet explored, such as "named areas", etc. It's an open question how much interactivity those will have in the canvas still, as these will very much need to be paired with container query functionality. The net result can still be cool, allowing you to design custom alignments in addition to wide and full-wide.

[ndiego]

I suspect this grid is in "auto" mode, whereas probably "manual" would've been a better experience in this case.

Here's another quick video with the layout in Manual mode. This usability issue still exists IMO.

grid-drag-handles-manual-mode.mp4

I wonder if a couple of things we can try is:

• Make manual default.
• Don't show resize handles in auto mode at all.

At least for 6.6, I would not make Manual mode the default because it's not responsive on mobile.

After I recorded the first video, I noticed another issue with the drag handles when you are expanding the column span. While they work better than the row span drag handles, it's impossible to reduce the column span of a block with the drag handles if you expand the block to the full width of the container. The video explains this better.

grid-drag-handles-column.mp4

[ndiego]

@ndiego what did you expect would happen when you first dragged the resize handle upwards on that 2x2 span block? I'm thinking it would be one of two things (please correct me if I'm wrong!)

I don't love the idea of overlapping content. I think this would be confusing for new users and can make it feel like something is broken.

I am not opposed to nothing happening if you try to resize the block in a way that "won't work." My main issue is that the drag handles increment the row span in this situation. So even though it looks like nothing is happening in the canvas, the attribute is changing, which will impact further edits the user makes.

[jasmussen]

I don't love the idea of overlapping content. I think this would be confusing for new users and can make it feel like something is broken.

The main reason I'm a big fan of overlapping is that this is one of the things grid does well, and most of the other blocks don't do at all, give or take the recent addition of negative margins. Additionally, allowing overlap enables the resizing in the canvas to actually be more immediately visible in more cases; in the PR review where this was changed to be allowed, the wrapping that would happen without the overlap was confusing similar to what you're describing in this issue.

[ndiego]

The main reason I'm a big fan of overlapping is that this is one of the things grid does well, and most of the other blocks don't do at all, give or take the recent addition of negative margins. Additionally, allowing overlap enables the resizing in the canvas to actually be more immediately visible in more cases; in the PR review where this was changed to be allowed, the wrapping that would happen without the overlap was confusing similar to what you're describing in this issue.

Fair point. I'll give that PR a test later today.

[tellthemachines]

I suspect this grid is in "auto" mode, whereas probably "manual" would've been a better experience in this case

@jasmussen are you thinking of the experimental Manual mode merged in #61025? I don't believe the experience of resizing will be much different between modes in 6.6, because both rely on auto-placement. In the experimental Manual mode with positioning, resizing in any direction will reposition the block exactly where the handles are dragged to.

what's the value of being able to resize in the canvas in auto mode if the results can be entirely unpredictable?

This is a good question! Could the experience be improved by hiding the top and left resize handles in Auto mode and only allowing items to resize down and right? It might be worth a try.

I'm very hesitant to disable anything altogether.

I think it's important when considering options to bear in mind that this interface is meant for users of all levels. Simplifying by reducing functionality might make things easier for beginners (though we haven't had any feedback yet from actual beginners, so we probably shouldn't theorise too much on this) but it'll limit what advanced users are able to do.

While layout tools are available in the editors for anyone to use, their main audience is theme and pattern builders, who are likely fairly advanced and know CSS to some extent, so if we're optimising for a particular demographic I think in this case advanced users would make more sense than beginners, though ideally things should work reasonably well for everyone.