Multivalue fields with long text elements can break the layout

[laryn]

Description of the bug

Multivalue fields with long text elements can break the layout, as reported in these locations:

• CKEditor 5 - multivalue textfields break layout #6364
• Field help text does not wrap but causes paragraph editor to expand to width of text backdrop-contrib/paragraphs#163 (This is in the Paragraphs queue but has been confirmed as a core issue on multivalue fields)

The first issue has a PR that is RTBC and likely to get into 1.27.0. However, @yorkshire-pudding and I have verified that the issue is not specific to CKEditor and is more general.

Cause

See backdrop-contrib/ckeditor5#125 (comment)

Solution

If we can fix the wider issue, then perhaps we can remove the CKE5-specific fix and avoid adding the same fix in multiple places. Adding this in system.theme.css right after the offending section solves both cases. Does that seem appropriate?

.field-multiple-table tr.odd .form-item,
.field-multiple-table tr.even .form-item {
  white-space: normal;
}

[herbdool]

Can we update this issue to elaborate on how to recreate the issue when not inserting long text into ckeditor 5? I can't recreate the bug in core, not with inserting long text into a text field with no editor, nor when putting long text into the help field in the field config.

[laryn]

@herbdool Thanks for looking. It looks like it may require a separate module to interact with it, which wraps the field with the long description in a multivalue table. e.g. Paragraphs, Multifield, Field Collection, custom code... If so, does that mean we leave it to each of those to fix if desired or is it still worth considering a broader fix in core?

[quicksketch]

Looking at the offending CSS, I'm not sure what it is actually attempting to do. Perhaps there are places in core where a checkbox or radio button is within a table and the label should not be wrapped? I might be inclined to remove the white-space: nowrap; rule and fix any places in core that would be affected (though I can't find any at first look).

[laryn]

I had the same thought... it feels extremely heavy handed to add a general no-wrap at that level.

[herbdool]

Yes, let's get a PR for that. Removing that rule altogether and test for any breakages.

[herbdool]

@laryn I've added a PR here to just remove that line. We seem to be in agreement on that. Testers can see if it breaks any layouts in core.

I took a look at the history of that line. It's really old. I could only see back 14 years to when it was moved to the current file, but couldn't find anything before that linked to an issue to explain why it was added.

[klonos]

Perhaps there are places in core where a checkbox or radio button is within a table and the label should not be wrapped? I might be inclined to remove the white-space: nowrap; rule and fix any places in core that would be affected (though I can't find any at first look).

Testers can see if it breaks any layouts in core. ...

I vaguely recall something related with that and mobile/narrow screens. I'll have to test.

[herbdool]

Perhaps there are places in core where a checkbox or radio button is within a table and the label should not be wrapped? I might be inclined to remove the white-space: nowrap; rule and fix any places in core that would be affected (though I can't find any at first look).

I have not found in core any checkboxes or radio buttons with a label and that are in a table. As for other form fields, the Manage Fields of an entity does have form fields in a table, but nowrap is already set there in field_ui.css:

.field-ui-overview tr.add-new td {
  vertical-align: bottom;
  white-space: nowrap;
}

(That css was added in https://www.drupal.org/node/1164812)

With either css I can't see any difference if I disable the nowrap or not, regardless of screen size.

@laryn can you test? Would be good to get this in.

[laryn]

I do not see any issues with removing this line in my testing (which was basically clicking around to a bunch of admin pages with complex tables in them, to be fair).

[quicksketch]

Thanks @laryn and @herbdool. With the manual testing by the 3 of us and finding no use-cases, that seems sufficient to remove this rule. If we do find a valid use-case, we'll remake the CSS for that situation, rather than blanket setting nowrap on all form items within all tables.