Flexible columns does not handle fractional columns (e.g. thirds)

[timhibberd]

Describe the bug
Flexible columns does not handle fractional columns (e.g. thirds).

To reproduce
Create a 3-column columns block and attempt to set the 3 columns to the same dimension 33.333%.

Expected behavior
I expect the entered value to be retained as 33.333%, 33.334%, 33.333%. Instead the columns are set to 33.5%, 33.5%, 33% or 33.25%, 33.75%, 33% . So it is not possible to have 3 columns of identical size.

Screenshots
None

Desktop (please complete the following information):

• OS: Windows10
• Browser Firefox
• Version 69.0.3

Additional context

• Not using the GB plug-in. Using WP 5.3-beta3-46461
• Latest Twenty-Nineteen theme

NOTE: Something that is not obvious is whether the column width settings represent percent of column block or percent of column block minus inter-block margins. So...for example...would 33.333% | 33.334% | 33.333% with 0% inter-column margins be presented in the settings the same way as 33.333% | 33.334% | 33.333% with 2% inter-column margins! So, for example, if the column settings were set to 33.333% | 33.333% | 33.333% the inter-column margins would be automatically set to .0005%. Alternatively if the column settings were set to 33% | 33% | 33% the inter-column margins would be automatically set to .5%

[aduth]

If I understand the issue correctly, it can be considered as the same as described in #16370. In other words, based on the discussion there, if we avoid (or allow some opt-out) of the "auto-adjustment" which currently occurs, then this issue will no longer occur.

In the meantime, it should be fine to do one or the other of the following as a workaround:

1. Create a new Columns block, and select the "Three-columns, equal width" predefined option
2. Manually edit the block in "Code Editor" mode (in top-right options menu) to assign the widths manually in the block attributes JSON and in the generated markup

[aduth]

Duplicate of #16370

[aduth]

There's actually a separate issue here in that the use of the range control (with <input type="number">) in the column block does not allow for decimal values, because of how the input validates the value (the Element#checkValidity on an input will report as being invalid if not also assigned a step attribute value).

This is included as part of the proposed changes in #19515 (0b2df9f).

[timhibberd]

@aduth - could you please re-open this. It is related to #16370 but not a duplicate. This is specifically about fractional widths. The other issue is related in that the solution to both involves the U.I. but they are solving different problems.

The problem being solved in #16370 is a UX issue in that changing one column width auto-changes other column widths.

The problem in this issue is how do we get an exact split when the widths are fractional...eg. 33,3333333333333333333333333333333333%

You see, the U.I. will want this to add up to 100 but UI simplicity will restrict it to 33 | 33 | 33 in the input fields which will add up to 99 so the software will want to add 1 to one of them. That is not acceptable...we want all 3 columns to be exactly the same width.

You may still want to consolidate this issue into the other issue but I would ask that you cut & paste across the problem statement as I have expressed it so this is not lost.

Thanks in advance.

[aduth]

@timhibberd There seems to be a few interrelated issues here:

1. The application will want to try to force the widths to equal 100%, and will automatically adjust column widths accomplish this. The UX concern here is already well tracked by Block Library: Avoid column width auto-adjustment when sibling width changes #19515.
2. The input does not accept decimal values. I think it could be fair to allow this issue to remain open to represent the issue here (described in your original comment, acknowledged in Flexible columns does not handle fractional columns (e.g. thirds) #17918 (comment), proposed to be fixed in Block Library: Avoid column width auto-adjustment when sibling width changes #19515).
3. How to represent fractions which can be represented only as repeating decimals (e.g. 1/3). At least in this common case of "columns of thirds", the default behavior of a Columns block where columns widths are explicitly unassigned will be such that the columns will be distributed evenly. In other words, if you remove the width value from each of the three columns, I would expect it would achieve the effect that each column takes up 1/3 of the available space. This is also how the predefined "Three columns; equal split" option is implemented. Are there other use-cases where this behavior would be insufficient? Is it an issue that this behavior is not discoverable?

[timhibberd]

First just let me say thank you for the work of you and the team. The columns block is a backbone block of many pages and I have had to hold off converting classic editor client sites until the flexible columns block is complete and in the core.

And thanks for re-opening this issue. So let's take a stroll down fractional columns lane...

a) Use case 1A: If a user does nothing when creating a 3-column block then the columns are proportional. Yes. Cool. But how would clients know that. The column block default UI is to highlight the first column with an enticing "click me" slider and a compelling "fill me in" empty column box. There is no visual default cue that indicates they can do nothing (selection highlight-box at the block level vs. at the column level | greyed out percentage in the box | "Use Default" checkbox that is checked).

b) Use case 1B: (corollary to 1A) As soon as the client moves the slider..and they will (hey man...cool slider) it gets filled with a percentage. Game over. Now we have the 100% whack-a-mole 33 | 33 | 34 or 34 | 33 | 33 or 33 | 34 | 33 fill / auto-fill dilemma.

b) Use Case 2: Four column block - 23.3333333% | 23.3333333% | 23.3333333% | 30%.

That's the problem. It is a universal UI-meets-implementation dilemma for fractions that is not specific to Gutenberg or this block.

Solution Options:
A) Look at some of the page builder plugins and see what creative solutions they came up with
B) Create our own UI solution.

Option1: Column grouping UI. Ouch...that seems a bit messy. There would also be the flex-dilemma...does a column group wrap as a unit on a small display!

Option2: Accept 1/X as an input alternative to percent. Could add a checkbox / toggle to block admin to require the user to explicitly switch between the units with 1/x being the default (which legacy WP users are familiar with from their shortcodes experience...[one_third][/one_third] ). It would also be good to display the default 1/X as grey text in the columns of a new column block.

Thoughts?

[timhibberd]

Actually...lets me correct Option 2 above. The checkbox is not switching between input units...it is enabling % input units. So the UI could like like this:

[timhibberd]

Following on from above the adjustment slider and adjustment column focus box would only be enabled / visible if the Adjust Columns block was checked.

[timhibberd]

Option 3: We add an "Adjust Units" toggle with the choices being "%" or "1/X (e.g. 1/3, 1/4)" and allow the user to enter in either units. When the user switches from % to 1/x it is rounded to the nearest unit regardless of what was set. So 31% | 35% | 34% would convert to 1/3 | 1/3 | 1/3 and 23% | 23% | 54% would convert to 1/4 | 1/4 | 1/2.

Option2 would be simpler though and require less testing. Option 2 is only a minor variant on what is there today.

[jordesign]

Just looping back to this issue. From what I can tell the fact that the columns block now uses CSS Flex for layout - means this issue should be resolved. I'm going to close this issue as no longer reproducible. If it is still proving to be an issue for you - please feel free to re-open with additional.