Use UnitControl instead of RangeControl for column width

[aristath]

I've got an itch I need to scratch... With FSE users will be able to use the editor to create their layouts. However, there is currently no way to create a layout with a side-header, or do a lot of other cool stuff.
The reason why they can't is simple: Columns are restricted to only use percent (%) values for their width.
This PR changes the control for column width from a RangeControl to a UnitControl, and makes all necessary changes to ensure backwards-compatibility and everything seems to be working the way it should. (see #24193)
The width control now looks like this:

The benefit of that is that we can now create a layout like this:

In the screencast above, the left column has a width of 250px and is the site header.
With percentage values that wouldn't be possible unless the user added custom classes and then custom HTML - which is totally possible but is the very thing Gutenberg was created to solve.
You can see there that resizing the viewport doesn't change the width of the 1st column since we used absolute units for that.

Though the range control is admittedly prettier, UnitControl allows for greater versatility and can accommodate many more scenarios.

---

EDIT:
Originally this PR aimed to allow arbitrary values for column widths.
Since then I realized the original plan was too ambitious and maybe too confusing for certain users. Some of the first commits here were using a TextControl and a custom validation function with notices. This is no longer the case and I switched it to UnitControl which is a more familiar pattern in the editor.

[carolinan]

I agree that this change is needed since it will enable more precise layouts.

I have tested the PR by creating a couple of column blocks without the plugin installed, and then activating the plugin (master + the pr). The original % values that were saved are working correctly in the editor and front.
I have edited the blocks and entered different values and the new values are saved as expected.

[aristath]

Comment no longer relevant since it refers to a previous implementation using a TextControl. (Click to expand)

Added some rudimentary values validation in dc3b8b7 with a notice in case the value is invalid. Example screencast with various units can be seen below:

[aristath]

Switched the plaintext input with validation to a UnitControl.
As a 1st step it's less ambitious but probably makes more sense.

[aristath]

@ZebulanStanphill I'm curious, why was the Needs Accessibility Feedback tag added here?
Was it perhaps referring to a previous implementation that had custom notices, validation etc instead of the now standard RangeControl?

[ntsekouras]

Hey @aristath! Thanks for working on this! - I haven't check the branch thoroughly because some more involved into these kind of things folks should have a better context/opinions. @ItsJonQ can you take a look here?

I have left some notes on the deprecation of the block though that I think you should check. I'm not 100% sure if I have missed something from the API or have understood something different, but seems worth asking a few things :)

[ItsJonQ]

@aristath Yay!! I made one minor adjustment to the UI (reducing the width of the input)

If this you're okay with this, then I think it's ready 👍

[aristath]

I made one minor adjustment to the UI (reducing the width of the input)

@ItsJonQ Looks great! ❤️ Yes, of course I'm OK with it.

[ItsJonQ]

Thanks @aristath for this update! 👍 from me

[lukewalczak]

Hello, I would like to discuss some aspects of that PR 🤔

1. I've noticed that your PR involved some kind of regression in Columns block, unless the new behavior is intended. Basically some functions such as hasExplicitColumnWidths or toWidthPrecision from columns/utils.js cannot work since there is a check Number.isFinite(value). Value always comes with the unit, so the result is false. Unfortunately it has an effect on columns width distribution (please notice that on presented gif, the third column width is different)

before PR	after PR

2. The second thing which I would like to raise is the fact that these changes (adding unit to the width attribute) are affecting the mobile part as well and unfortunately we have a crash when user is changing columns width and saving the post. The PR template should have Checklist, where one of the bullet is:

I've updated all React Native files affected by any refactoring/renamings in this PR..

I'm aware that it can be hard to run the mobile, but you can always ping someone from mobile team to test and confirm if changes don't break anything.

3. The third point is that Columns on mobile accepts only % so I don't know how it will behave when user on web will set:

• first column: 100px
• second column: 50%

and then will open the post on mobile app.

[youknowriad]

@aristath What do you think about the regressions above? Can we fix this on time for 5.6 or should we revert this PR temporarily?

[lukewalczak]

One more thing to note is that function in columns/utils called getTotalColumnsWidth used within getRedistributedColumnWidths sums the width attribute of the individual column defined in % (correct me if I'm wrong). With the approach where width can be defined in different units, function mentioned above should take into account somehow.

[aristath]

I currently have to focus on the twentytwentyone theme if we want to make the deadline, so I can't work on this issue this week.
If nobody else is willing to fix the issues then reverting it temporarily for the 5.6 release is the only option. 👍

[ceyhun]

Created a PR to temporarily revert: #26056

[ntsekouras]

I think even the revert could potentially affect other merged PRs (after this one) that had to do with Columns block. For example it will affect this one: #25829.

And this one is I know because I was the author. There could be many more... 🤔

[gziolo]

@tellthemachines, @ntsekouras - this one might need isEligible check. width might be not set at all. It's very likely we can avoid adding another deprecation in #26757.

[gziolo]

It also creates some issues when adding a new column because it still uses number values. See #27756.