Block Library: Column: Limit width redistribution to adjacent column

[aduth]

Closes #16370 (cc @phpbits)

This pull request seeks to improve the behavior of column width assignment to limit impact on other columns, to redistribute width relative only the block immediately adjacent the one being resized, rather than split amongst all other blocks in the set. It is hoped that this should be a more predictable behavior for resizing, particularly when aiming to resize multiple columns.

Testing Instructions:

Verify that resizing a column adds or removes width from the column immediately to its right (if the column is the last in the set, it adds or removes from the column to its left).

[talldan]

I know @aduth is not around at the moment to follow up, but I thought I'd give this a review.

I don't think the approach taken is quite right. Even though this should prevent non-adjacent columns from changing I still see them moving when I'm resizing. In testing I used three columns (one of the predefined layouts).

I think the issue is due to the current calculation not being quite right, and it's causing some glitchy widths. For example, If I add width onto column A it should take it from column B. But if column B doesn't have any more width to give it ends up with a negative percentage. I think column C then adjusts to take up that 'negative' percentage space. I noticed it was also possible to get more than 100% for a column width if you mess around enough.

I also tried typing specific widths into the columns to make them exact (e.g. 25, 25, 50), but the trouble is that as soon as you type the adjacent column re-adjusts, it actually seems very hard to type the desired widths.

Some options:

• Make it simpler. Don't bother adjusting the other column percentages when changing a width, just let flexbox handle it. This means you can have more than 100% if you add up the columns, but it never breaks, and it makes it easier to type in exact percentages. The number could be presented as the 'width proportion' instead. It seems like this would just require deleting some code!
• Make it more complicated. Use the current approach, but at a certain point of adjusting column A, when column B has no more width to give it has to be taken from the successive remaining columns one-by-one. I think the columns need to also have a max width based on the total number of columns. E.g. if there are 5 columns, the other four columns each have a min width of 1%, so I should only be able to resize an individual column to 96% ( sum( [ 96, 1, 1, 1, 1 ] ) // === 100).

[talldan]

Some further thoughts (as if I hadn't written enough)

• It feels like this UI should be on the columns block, so that each column can be adjusted quickly, rather than clicking into the individual column. The issue with typing column width would also be solved if there were multiple range inputs and an 'apply' button.
• It's a shame that after selecting a column template, those predefined options then disappear. I could imagine them being quite useful (e.g. if I have three columns, show a few buttons with predefined width settings for three columns).

[aduth]

It feels like this UI should be on the columns block, so that each column can be adjusted quickly, rather than clicking into the individual column. The issue with typing column width would also be solved if there were multiple range inputs and an 'apply' button.

Related: #15660, #16077

[aduth]

Make it simpler. Don't bother adjusting the other column percentages when changing a width, just let flexbox handle it. This means you can have more than 100% if you add up the columns, but it never breaks, and it makes it easier to type in exact percentages. The number could be presented as the 'width proportion' instead. It seems like this would just require deleting some code!

I recall considering this, and I can't remember specifically why it was this wasn't the direction taken. As you allude, it would remove some of what exists today in enforcing that the columns will always sum 100% width by allowing the user direct control over each of those values.

I'm unsure, but there may be some challenge in applying those flex styling within the editor, though I don't think that should necessarily affect the decision for what is the most correct approach here.

[aduth]

Following discussion at #19515, I rebased this branch to explore what might be necessary to resolve the outstanding issues presented in @talldan's earlier review. The current branch represents a revised approach where, when the width of a column changes, it will take or add to the immediately adjacent block, and if that block has no width to give or receive, it will consecutively step through and repeat this adjustment on as many of the remaining adjacent blocks as necessary.

It works reasonably okay, but there are a few non-obvious scenarios to try to deal with, where each could have the potential to be an unexpected change from the user's perspective:

• If adjusting a column in the middle of a Columns, if all of the following blocks' adjustments would not be enough to satisfy the new width value, from where should the adjustment proceed?
  • In this implementation, it will "start over" from the beginning.
  • Example: 25 | 65 | 10 | 10, adjust the third to 25, the result is 20 | 65 | 25 | 0
• When adding a column to an existing set of columns, how should the width of existing columns be impacted?
  • In this implementation, the width of the new column is equal to 100 / newColumnCount, and the width adjustment occurs the same as if we were adjusting the width of the last column in the set.
  • Example: 33 | 33 | 33, add a column, the result is 33 | 33 | 8 | 25
• When removing a column from an existing set of columns, how should the width of remaining columns be impacted?
  • In this implementation, the width is granted as if we were adjusting the width of the last column in the set.
  • Example: 25 | 25 | 25 | 25, remove a column, the result is 25 | 25 | 50
• When setting an explicit width for the first time to a column, how should the width of the sibling columns be impacted?
  • In this implementation, the widths are assigned and adjusted as according to the effective width they would have been expected to occupy.
  • Example: undefined | undefined | undefined, set a width of 20 on the second column, the result is 33.3 | 20 | 46.6

A live environment for testing is available at: http://gutenberg.run/16822

Note: The implementation is rough, and I've not yet updated the tests. The above behaviors may in-fact be buggy or not working correctly, but I've described them as to what my expectation would be based on how I approached the implementation. By sharing early progress, my intent is to illustrate that, while this approach can be more predictable in many ways than the existing implementation, there are a number of scenarios where the expected outcome of a width adjustment may not be immediately obvious to a user.

I also think it could make sense to consider sensible maximums and minimums in the adjustment. The above examples show that it can be possible to arrive at a scenario where a column in a set of columns could have 0% or 100% widths. This is probably not desirable. However, it's unclear to me (a) what these minimums and maximums should be (@talldan implied 1% in his earlier comment) and (b) what impact we could expect this to have in making the adjustments more or less predictable.

Consider again this example:

Example: 25 | 65 | 10 | 10, adjust the third to 25, the result is 20 | 65 | 25 | 0

With a minimum column width of 1%, the result would end up being 19 | 65 | 25 | 1 instead, which may be even more unpredictable than it would have already been.

[timhibberd]

Just going to list a few quirks which you may already be aware of:

1. Moving the slider back-and forth I managed to get it stuck in a position where the 3rd column is not selectable at all. Once I made the middle column smaller the 3rd column got larger and was selectable again.

2. You can only select the column block if you know to click in one of the inter-column margins! I had to click all around to figure that out. I thought clicking above, or below, or to the left of the first column or to the right of the last column would select the column block but it doesn't. That's going to frustrate some of my clients...they'll give up, call me to complain, I'll tell them to click in between...they'll then feel foolish and vent some more to save face. Would be great if selecting the block was more intuitive :-)

3. If you select a column and move the slider to the far left the column goes to minimum size but the slider jumps back to the middle!

4. When using the slider to vary the column-size (larger and smaller) experimentally to gain perspective the column block quickly becomes messy and you need to press the reset button and start over or manually adjust the boxes one-by-one:

5. When editing a column, the reset button does not reset that column's width to the default as one might expect...it is actually a block-level reset button and resets all the columns back to their default. That won't be obvious to the end-users. Maybe rename it "Block Reset".

[aduth]

Since #19515 is merged, this is no longer immediately applicable. It may be revisited as discussion of columns widths controls continues.