Row / Group block child offers dimension width "fixed" which in reality is "proportional" (flex-basis)

[porg]

Either the implementation of the fixed width as flex-basis: <width + unit> is wrong or the wording in the Inspector is wrong/misleading! See my video recording with explanatory audio (2m30s):

Row.block.child.offers.dimension.width.fixed.which.in.reality.is.proportional.flex-basis.mp4

Reproduction

• Create a Columns block with 2 columns, no dimension set at all, which defaults to split it 1:1.
• In the first column create this block structure:
  • Row block
    • Paragraph Block 1 — 1-2 Unicode symbol(s) which shall have a uniform width, e.g. 2em or 48px
      • Dimensions → Width: Fixed: 48px (implementation → flex-basis: 48px)
    • Paragraph Block 2 — Text of variable length. Shall take the remaining width. Wrap on multiple lines if needed.
      • Dimensions → Width: Fit or Fill.
• Duplicate that structure as a second instances and place it in the second column.
• In one instance the Paragraph Block 2 text fits on 1 or 2 lines. In the other on 3 lines.

Actual: The Paragraph Block 1 is the two instances is not uniformly at the "fixed" site of 48px, but varies!

Expected: The fixed block really has that fixed width. And not acts proportionally behind the scene.

[porg]

Also if paragraph block set to fixed plus margin → Then still only proportional

Also.if.paragraph.block.set.to.fixed.plus.margin.-.Then.still.only.proportional.mp4

Only workaround: Rebuild as columns

Workaround.-.Rebuild.as.columns.mp4

• which is a bit overkill
• Would prefer if the Group block (in row mode) could handle that.
  • More minimalist
  • Use cases where this may be the only/proper way to go
  • Any the wording in the Inspector as "Fixed" is plain wrong and misleading

👉 So something certainly must be improved here.

[tresorama]

If you (in the dev tools of a frontend render) manually add flex-shrink: 0 to paragraphs with "flex-basis:48px" do you get what you expect?

[porg]

👍 That fixes it

Adding flex-shrink: 0 as an extra attribute makes flex-basis: 48px not behave proportionally anymore but sets this as a fixed width, as the Inspector labels promise.

▶️ Video of what it does in the frontend

Row.block.child.with.flex-basis.with.length.changes.from.proportional.to.fixed.when.combined.with.flex-shrink.0.mp4

• On the right instance the difference is immediately noticible. The symbol paragraph is now really 48px wide.
• On the left symbol paragraph, which seemed already fine right from the beginning, toggling flex-shrink: 0 brings no noticeable change on a 1280px viewport. On a bid wider viewport like 1400+ px one can notice that the second paragraph font slightly re-renders (its width gets reduced by 2px from 498px to 496px).

👉 Fix Proposal

• I guess it would be the correct fix to add that extra CSS attribute flex-shrink: 0 when setting Dimensions → Width: Fixed: <length Unit> to a child of a Row block such as a paragraph block.

[tresorama]

• I guess it would be the correct fix to add that extra CSS attribute flex-shrink: 0 when setting Dimensions → Width: Fixed: <length Unit> to a child of a Row block such as a paragraph block.

I think the same.
Also this sound like a bug that can be overcomed with two ways:

• add flex-shrink: 0 when setting Dimensions → Width -> Fixed.
• or add a new Dimensions -> Width -> Fixed Not Flexbile with flex-shrink:0, and keep both this and the current implementation (with good differentation naming)

I think the first solution is more easy to handle for the consumer of the editor, and make more sense for a "Fixed" value.
But i almost never used the "Fixed" width settings so i don't know any potential conflict with other layout features.

We must wait intervention from core devs

[tellthemachines]

I'm sorry about this, it's a known issue since #46139. You can have a read through the discussion in that PR for more context. The tl,dr is that there will be a control to change this behaviour at some point.

[iamtakashi]

I hope this issue will be fixed soon. It's counterintuitive that the fixed-width value isn't respected. Look at the size of the squares; they are all different sizes because of the length of the paragraph next to them. This is a likely scenario, and the fixed option is currently unusable.