Prefix/Suffix not inline with autocomplete field

Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to our policies.

I'm able to reproduce the issue in Drupal core 11.x . Steps followed:-

1. Created a new text field and entity reference field with limit 2 in the content type 'Article'
2. Created a custom module.
3. Added 'field_prefix' and 'field_suffix' for both the newly created fields using custom module.
4. For text field, prefix and suffix are coming as inline but for entity reference it’s not.

Attached screenshots for reference

I tried the suggested solution i.e., changing width: auto; for the entity reference input element and it fixes the issue. Also, created an MR for the same.

Noticed that entity reference field without limit doesn’t have 100% width. So making the above changes, both type of entity reference fields will have same width. I'm not sure if that is an issue here.

Have not reviewed.

MR has build issues.

One file was missing in the commit. I have added that and now the build issue is fixed. Kindly review.

Seems like a straight enough fix.

This is changing the UI so tagging. That got me looking for screenshots. The latest before and after screenshots should be available from the issue summary, in the "User interface changes" to help reviewers. Fortunately, there are only a few comments here so I found that in #9. They look correct but why is there a screenshot of 'tags', https://www.drupal.org/files/issues/2024-09-05/3471459-entity-reference-...?

The proposed resolution questions why the value is "100%" and then says that removing it or changing it to 'auto' works. The implemented solution uses 'auto' but there is no discussion of why that option was chosen, nor is there any investigation in to why it is 100%.

This seems like a good thing to have a test for, to prevent regressions.

There is one observation :- the issue mentioned in the ticket occurs when Autocomplete widget is used in the form display whether the field is limited or unlimited. If Autocomplete (Tags style) widget is used, then this issue doesn’t occur.
The screenshot of 'tags' was added just to show how an entity reference field with unlimited value + Autocomplete (Tags style) widget looks like in the form. As you can see in the screenshot, the width of that field is not set to 100%. When Autocomplete widget is used, the field appear as a table and width: 100% was set to the input elements and I think it was done so that it will cover the entire row of the table. Attaching a screen recording of entity reference field without prefix/suffix and toggling width:100%.

I'm not sure if we can remove width completely here. Better to write tests.

Updated IS with before and after screenshots.

The comment in #14 sounds like we have an unintended regression here.
Would it be better to set the parent element that contains the two prefix spans and the form element to display flex, setting flex-grow on the form element. That way it would be 100% if there's no prefix/suffix but otherwise they'd all be on the same line.

Thanks! @larowlan for the suggestions. I have implemented those changes except flex-grow since form element seems to be getting adjusted correctly even without flex-grow because of width:100%. Below are the changes done in this commit:-

1. Added display: flex to parent element that contains the two prefix/ suffix spans and the form element
2. Reverted width: 100% of form element.
3. Added spacing for prefix and suffix referring to the style used for suffix in form.css for screen width above 601px. As I'm not sure why that breakpoint was used in form.css, I added them without breakpoints in table.css

After the above changes this is how the fields looks like and I think it's is much better than previous implementation:

Updating IS screenshots as well.
Please review.

Believe feedback has been addressed on this one.

Pinging FE framework managers to confirm they're ok with this.

I checked a few spots with table cells that contain .form-item and I saw that in taxonomy term tables the "Status" items are no longer aligned with their header.

Hi @bnjmnm

the issue you mentioned i am unable to reproduce let me know if i am missing something.

step i followed --

1.go to taxonomy
2.click on any list term
3.add 3 terms used one of them to nest inside one term.

Removing justify-content: center fixes the alignment of Status items.

Hello,
Getting error while applying MP.
Attaching error screenshot-

Issue Fixed for me applied MR manually. RTBC+

@saurav-drupal-dev there's already a valid set of screenshots on the issue, additional ones aren't needed. Thanks.

Status regression appears to be addressed.

Committed bffe969 and pushed to 11.x. Thanks!

The fix from this issue (commit 937a5478) introducing display: flex on the .form-item seems to be causing some layout regressions elsewhere—specifically with multi-value Link fields.
The details are here #3532656: Multi-Link Fields styling applying flex class.

Too many side effects, reverting

For some reason the revert commit didn't link up here.

https://git.drupalcode.org/project/drupal/-/commit/9ce9ba1c8d0c4d13dd0a3...

I am giving credit on this issue to people who contributed to #3519949: [regression] Claro CSS selector 'td > .form-item' should be more specific: it targets many fields and the Permissions form. I may be too stingy: I did not give credit to the authors of Comments 2, 4, 5, 6, 10, 12 , 13, 16, 18, nor myself.

For testing purposes, see Comment #34 (@marcoliver) from that issue:

I have now also attached the quick and dirty module I whipped up for testing. It basically just does some preprocessing and attaches itself to any field whose machine name starts with field_related_.

(I took the liberty of making "quick and dirty module" a link to the zip file.)

Thanks for the revert. If we do take something like this on, we should likely be specific about which `td` we're targeting. Is there a parent class that we could hit?

For what its worth, I opened a branch/an MR with an attempt at what I proposed a while back in the regression issue: to conditionally wrap prefix, field, and suffix in another element and apply the styles from the original fix to that wrapper instead.

Could this perhaps be a workable approach?

Anyway to do this without the twig change? Only ask because then we need a CR as other themes will have

@smustgrave:

Did your comment get truncated?

The markup in 11.x looks something like this:

<div class="js-form-item form-item js-form-type-entity-autocomplete ...">
  <label for="edit-field-related-content-0-target-id" class="...">...</label>
  <span class="form-item__prefix">Prefix</span>
  <div class="claro-autocomplete">
    <input ... type="text" ...>
    <div class="claro-autocomplete__message hidden" data-drupal-selector="autocomplete-message">Loading…</div>
  </div>
  <span class="form-item__suffix">Suffix</span>
  <div class="form-item__description"> ...  </div>
</div>

The change that had to be reverted (which you marked RTBC in Comment #29) made any td > .form-item a flex container. That caused lots of problems, as discussed in #3519949: [regression] Claro CSS selector 'td > .form-item' should be more specific: it targets many fields and the Permissions form. Even if we add a class to the wrapper div and target that class, we have the problem that the wrapper contains the description after the prefix, input, and suffix. That leads to this behavior (screenshot from the description of #3519949):

@marcoliver:

I think this is the right direction, but there are some problems. Just as @ifrik pointed out in Comment #27 on #3519949, it does not work well on narrow screens. Another problem I noticed is that there does not seem to be any padding nor margin between the prefix and the input field. This gets even worse (at least on Firefox/Linux) when the input has focus:

I am setting the status to NW.