- Issue created by @marc.bau
- ๐ณ๐ฟNew Zealand quietone
Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to our policies.
- ๐ฉ๐ชGermany marc.bau
The 100% width is also causing the issue in #3471683
- First commit to issue fork.
- Merge request !94203471459: Fix prefix or suffix not inline with autocomplete field issue โ (Open) created by Unnamed author
- Status changed to Needs review
4 months ago 6:24am 5 September 2024 - ๐ฎ๐ณIndia nayana_mvr
I'm able to reproduce the issue in Drupal core 11.x . Steps followed:-
- Created a new text field and entity reference field with limit 2 in the content type 'Article'
- Created a custom module
- Added 'field_prefix' and 'field_suffix' for both the newly created fields.
- 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.
- Status changed to Needs work
4 months ago 1:23pm 5 September 2024 - Status changed to Needs review
3 months ago 1:56pm 9 September 2024 - ๐ฎ๐ณIndia nayana_mvr
One file was missing in the commit. I have added that and now the build issue is fixed. Kindly review.
- ๐ณ๐ฟNew Zealand quietone
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.
- ๐ฎ๐ณIndia nayana_mvr
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 to100%
. When Autocomplete widget is used, the field appear as a table andwidth: 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 togglingwidth:100%
.I'm not sure if we can remove
width
completely here. Better to write tests.Updated IS with before and after screenshots.
- ๐ฆ๐บAustralia larowlan ๐ฆ๐บ๐.au GMT+10
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. - ๐ฎ๐ณIndia nayana_mvr
Thanks! @larowlan for the suggestions. I have implemented those changes except
flex-grow
since form element seems to be getting adjusted correctly even withoutflex-grow
because ofwidth:100%
. Below are the changes done in this commit:-- Added display: flex to parent element that contains the two prefix/ suffix spans and the form element
- Reverted width: 100% of form element.
- 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. - ๐ฉ๐ชGermany marc.bau
Great. That looks visually much better than my quick fix.
- Status changed to RTBC
about 1 month ago 5:42pm 18 November 2024 - ๐บ๐ธUnited States smustgrave
Believe feedback has been addressed on this one.
- ๐ฆ๐บAustralia larowlan ๐ฆ๐บ๐.au GMT+10
Pinging FE framework managers to confirm they're ok with this.
- ๐บ๐ธUnited States bnjmnm Ann Arbor, MI
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.- ๐ฎ๐ณIndia ahsannazir
ahsannazir โ changed the visibility of the branch 3471459-prefixsuffix-not-inline to hidden.
- ๐ฎ๐ณIndia ahsannazir
ahsannazir โ changed the visibility of the branch 3471459-prefixsuffix-not-inline to active.
- ๐ฎ๐ณIndia ahsannazir
Removing
justify-content: center
fixes the alignment of Status items. - ๐ฎ๐ณIndia sagarmohite0031
Hello,
Getting error while applying MP.
Attaching error screenshot-