Form prefix/suffix redesign in Claro

I used width: auto override on 600px and below because the 100% width pushes the suffix to a new line.
(Claro 8.x-1.x dev with Drupal 8.7.7)

The #field_suffix and #field_prefix are not specific to '#type' => 'number'. We should try to find solution that works with all field types without having to remove this usability enhancement.

I added a new class to wrapper form-item if it contains prefix or suffix element.
(UPDATE: wrong patch)

Did you post the right patch? I don't see any new classes being added in #4 🤔

Sorry @lauriii, I uploaded the wrong patch, this is the good one:

This fixes the problem on Chrome, but it seems like width: auto isn't enough to fix this in Firefox.

+++ b/templates/form-element.html.twig
@@ -24,6 +24,8 @@
+    prefix is not empty and disabled != 'disabled' ? 'form-item--prefixed',
+    suffix is not empty and disabled != 'disabled' ? 'form-item--suffixed'

Any thoughts on renaming these to form-item--with-prefix and form-item--with-suffix?

Ok, it's no problem, I rename the classes and try to fix the FF bug!

I need to add max-width:75% (or any other value) to the suffixed/prefixed input field on 600px and below because the field's width isn't working exactly as on Chrome. The field's default width is much wider on FF and IE. When I tested it on FF and IE, the width: auto is working, but the suffix is pushed to a new line on 320px screen, so the max-width: 75% is fixed this bug. Any other suggestion?

This looks like the current patch comes with the result that suffixed inputs works well but we only get 75% of the width for prefixed inputs like in

/admin/config/system/site-information

Ideally, the prefix, suffix and input sharing one parent container where we could define a variable (but fixed min-) width for the input and let the prefix and suffix flow but that would also cause other problems. The main problem here is that we can't assume the width of prefix or suffix because they can be any length. Imho, it can be leaved as is (because of edge case) but if we want to improve it we need to have in mind that on other places, it could be worse with this change.

Setting it to RTBC because the patch works and fixes the problem, but the concerns are described in #13

Another solution is when a JS calculate the width of the prefix/suffix, and it updates the input field's width (subtract from it). I know, it's not the perfect solution, but more accurate than playing with the max-width value. Should I try, maybe? (In this case, the JS is running after the DOM is rendered, so in some cases, it causes a little jump when the prefix/suffix is longer than 25% when we will use the 75% input field's default max-width.)

Let's try what happens if we add a wrapper for the input and its prefix and suffix (when at least #prefix or #suffix is set), and use flex for styling them.

|prefix                         |input          |suffix                        |
================================================================================
|flex: 0 1 20%;                 |flex: 1 0 60%; |flex: 0 1 20%;                |
|max-width: calc(20% - 0.5rem); |               |max-width: calc(20% - 0.5rem);| 
|margin-right: 0.5rem; /* LTR */|               |margin-left: 0.5rem; /* LTR */|

Screenshot for #16:

@huzooka Very good idea, I'll give it a try!

Note: /admin/config/user-interface/shortcut/manage/default
This is a place where the break into a new line makes sense for suffix.

I tried @huzooka's idea, and it's working.

Rebased what we had in #21.

I apologize, I just realized that this issue is assigned to @pzajacz.

@huzooka I removed my assign! ;)
I think this task needs review and testing, or you know anything is missing from the patch?

Setting to needs review because of the rebased patch.

1. +++ b/core/themes/claro/css/src/components/form.pcss.css
   @@ -114,6 +114,42 @@ tr .form-item,
   +  .form-item .form-item__wrapper {
   

   This could be simplified to just .form-item__wrapper.

2. +++ b/core/themes/claro/css/src/components/form.pcss.css
   @@ -114,6 +114,42 @@ tr .form-item,
   +  .form-item--with-prefix .form-item__wrapper .form-element,
   

   This could be simplified to:

   .form-item--with-prefix .form-element,
   .form-item--with-suffix .form-element
   

3. +++ b/core/themes/claro/css/src/components/form.pcss.css
   @@ -114,6 +114,42 @@ tr .form-item,
   +  .form-item--with-prefix .form-item__wrapper .form-item__prefix,
   +  .form-item--with-suffix .form-item__wrapper .form-item__suffix {
   

   This could be simplified to:

   .form-item__prefix,
   .form-item__suffix 
   

4. +++ b/core/themes/claro/css/src/components/form.pcss.css
   @@ -114,6 +114,42 @@ tr .form-item,
   +  .form-item--with-prefix .form-item__wrapper .form-item__prefix {
   ...
   +  [dir="rtl"] .form-item--with-prefix .form-item__wrapper .form-item__prefix {
   

   These could be simplified to .form-item__prefix and [dir="rtl"] .form-item__prefix.

5. +++ b/core/themes/claro/css/src/components/form.pcss.css
   @@ -114,6 +114,42 @@ tr .form-item,
   +  .form-item--with-suffix .form-item__wrapper .form-item__suffix {
   ...
   +  [dir="rtl"] .form-item--with-suffix .form-item__wrapper .form-item__suffix {
   

   These could be simplified to .form-item__suffix and [dir="rtl"] .form-item__suffix.

6. +++ b/core/themes/claro/templates/form-element.html.twig
   @@ -36,6 +38,9 @@
   +  {% if prefix or suffix is not empty %}
   +    <div class="form-item__wrapper">
   +  {% endif %}
   
   @@ -48,6 +53,9 @@
   +  {% if prefix or suffix is not empty %}
   +    </div>
   +  {% endif %}
   

   I'm just wondering if it would make sense to simplify this component by always rendering this wrapper. 🤔 Any thoughts?

+++ b/core/themes/claro/css/src/components/form.pcss.css
@@ -114,6 +114,42 @@ tr .form-item,
+  .form-item--with-prefix .form-item__wrapper .form-element,
+  .form-item--with-suffix .form-item__wrapper .form-element {
+    flex: 0 1 60%;
+  }

This limits the input with in 60%. I think that what we need here is flex: 1 0 60%;.

Fixing the tag to be Amsterdam2019. I'm removing the novice at the moment as well, but will probably add it back on Wednesday.

Fixing the tags is a little confusing because we are working with this tag to identify issues which fit in the contribution during DrupalCon. Other projects use different tags but we decided to use this one. Would be nice if we keep the current tag, thanks.

Thanks a lot for your effort and time investment.

Sorry, for removing many of the tags, @fhaeberle. Usually core issues will follow the pattern [CITY]YYYY. Having a consistent tag for core issues helps contributors searching for novice issues. I'll leave this one though.

Edit: it also helps contribution event organizers and DA staff aggregate statistics for the event.

Working on it at DrupalCon Amsterdam 2019.

retagging

I adjusted the patch with the mentioned comments. I will also add the interdiff.

Hi, I'll be testing/reviewing this patch.

Thanks for the patch and thoughts.

So the input suffix on admin/config/media/image-toolkit and admin/config/user-interface/shortcut/manage/default looks great in Chrome/Safari/Firefox.

For the admin/config/system/site-information, however, the front-page input gets before the prefix. As described in #13 if I understand correctly.

Also, the input exceeds the screen in Firefox:

This patch:

• Makes prefix, item and suffix sizes more flexible
• Makes machine name suffix rendered in a new line

Handcrafted screenshots attached.

Any thoughts on #26.6?

Visually this looks good:

Still not addressing #26.6, this is only a rebase (without #3094696-3: Follow-up to #3084843: Re-generate production CSS files).

The attached patch addresses #26.6.

Mobile screenshots attached, others in progress.

OSX screenshots attached.

Remaining:
IE11, MS Edge, Chrome on Windows and Ubuntu, Firefox on Windows and on Ubuntu.

Re-rolled #48.

Here are the new designs for the prefix/suffix with a solution for the mobile/small spaces. I just updated the issue summary too.

This is a partial review up to form--text.pcss.css to try to make this a bit more digestible.

1. I understand moving "x" and "pixels" to their own render array elements, but I'm not confident enough here to say whether or not there's a better way to handle the schema issue, so I would rather defer to others with more expertise there.

2.

+++ b/core/themes/claro/css/components/form--prefix-suffix.pcss.css
@@ -0,0 +1,141 @@
+.form-item__affix {
+  box-sizing: border-box;
+  border: 1px solid var(--color-lightgray);
+  background: var(--color-lightdiamond);
+}

This selector is duplicated.

3.

+++ b/core/themes/claro/css/components/form--prefix-suffix.pcss.css
@@ -0,0 +1,141 @@
+.form-item__affix {
+  display: flex;
+  overflow: hidden;
+  flex-direction: column;
+  justify-content: center;
+  padding: calc(var(--space-xs) / 2) var(--space-xs);
+  white-space: nowrap;
+}

I can't quite figure out why the overflow:hidden is necessary here, but that may just be me missing something.

4.

+++ b/core/themes/claro/css/components/form--prefix-suffix.pcss.css
@@ -0,0 +1,141 @@
+.form-item__affix--empty {
+  padding-right: 0;
+  padding-left: 0;
+}

I'm still seeing a bit of a gray box here, so I think a border:none might be a good idea.

5. At small breakpoints, and only on the "Number prefix suffix" test page, the label does not span the full width of the input element. This happens in Chrome, Firefox, and IE. See screenshot below:

6. In IE, the focus border is obscured when the prefix and suffix are stacked. See screenshot below:

I've confirmed that the issues in #66 are addressed, and this is everything else I could find:

1.

+++ b/core/themes/claro/js/prefix-suffix.es6.js
@@ -0,0 +1,261 @@
+      $(input).on('formUpdated.machineName', prefixSuffix);
+
+
+      // When CKEditor is ready, the input widths may change. The prefixes and

Extra line.

2.

+++ b/core/themes/claro/js/prefix-suffix.es6.js
@@ -0,0 +1,261 @@
+    /**
+     * Determine the width of as affixed form input inside a table cell.
+     *

Nit: typo (an affixed?)

+1 to more comments. :)

I've tested this with Firefox, Chrome, and IE, and with the form variations provided by the Prefix Suffix Claro dev tools module.

I've manually located and tested each css selector, and I can't find any additional issues.

+++ b/core/modules/editor/config/schema/editor.schema.yml
@@ -40,3 +40,9 @@ editor.editor.*:
+            ex:
+              type: ignore
+              label: 'x'
+            pixels:
+              type: ignore
+              label: 'pixels'

How come config schema is changing here? These shouldn't be making it into config. If something is failing because of config schema then it means that this form elements are resulting values being saved in configuration. that shouldn't be happening here.

Re-titling as the scope sounds huge from the title.

It seems like item elements get added to form state regardless of its documentation. I opened an issue for this: #3164524: Item elements are added to form state. In the mean while, we could consider using for example inline templates for rendering the form element separators.

Should we open a follow-up to convert these to use #type => item once #3164524: Item elements are added to form state has landed?

This simplified approach looks great to me and works. Marking as RTBC.

Just a light review.

Great to see the manual testing done here, See #70. As a review it would be nice to have that in the issue summary.

I do see that patch has coding standard errors, https://www.drupal.org/pift-ci-job/1795540. Setting NW for that.

A bit of feedback I have after testing the patch:

1. 
   I'm not sure it makes sense to apply this pattern for the generated machine name use case.
2. 
   While it looks good to align text to right on the fields that have a suffix, using it feels really strange. I think we should consistently align text on left when in LTR.
3. The color contrast seems to be sufficient in terms of color contrast checkers. However, I find it quite difficult to read text in the prefix and suffix. Couldn't we increase the contrast by using a lighter shade of gray without having too much of an impact on the design?

@lauriii

While it looks good to align text to right on the fields that have a suffix, using it feels really strange. I think we should consistently align text on left when in LTR.

+1, agreed

The color contrast seems to be sufficient in terms of color contrast checkers. However, I find it quite difficult to read text in the prefix and suffix. Couldn't we increase the contrast by using a lighter shade of gray without having too much of an impact on the design?

We could use a lighter shade yes. But I'm not sold on using borders like @bnjmnm did in his approach.

100% agreed with what @saschaeggi said. This big contrast between the border and the background is too much. What about something like this that we tried at the beginning?

@ckrina I would just increase the text a bit more (also because of the feedback of the contrast)
Maybe like this:

White Smoke bg, Light Grey border, Davy's grey text color)

We've discussed this (@ckrina, @lauriii & @bnjmnm & I) in Slack.

I've updated the specification for this in Figma: https://www.figma.com/file/OqWgzAluHtsOd5uwm1lubFeH/Drupal-Design-system...

Also here as a screenshot:

That was even quicker @bnjmnm 😉💪

Based on https://api.drupal.org/api/drupal/developer%21topics%21forms_api_referen... #field_prefix and #field_suffix could be used in checkbox, machine_name, password, password_confirm, radio, select, textarea and textfield form elements. Let's make sure that we test all of them.

I had to link Drupal 7 documentation because I couldn't find this documentation page for Drupal 8 or 9. Closest what I could find was https://www.drupal.org/docs/8/api/form-api/form-render-elements which doesn't mention #field_prefix or #field_suffix but only talks about #prefix and #suffix which are different.

Updated the design in the issue summary

This also breaks Views UI path configuration for page views:

I see an issue with password fields.

The confirm password field shouldn't be visible until a password is entered, and the input and strength indicator are too wide.

before:

after:

The fix in #97 makes sense to me, and that was the only thing I found to report in #96 after reviewing the code, including the recent style updates.

I believe this is ready to RTBC when #2336569: Remove incomplete <span> usage from #field_prefix and #field_suffix is committed (it's currently RTBC).

Since #2336569: Remove incomplete <span> usage from #field_prefix and #field_suffix has been committed, I believe everything is resolved sufficiently to mark this as RTBC.

I've opened #3174118: Text area prefix/suffix on Claro as a followup to improve the designs for the text area suffix and prefix.

1. +++ b/core/modules/editor/editor.admin.inc
   @@ -106,10 +106,13 @@ function editor_image_upload_settings_form(Editor $editor) {
   +    '#type' => 'inline_template',
   
   @@ -120,9 +123,11 @@ function editor_image_upload_settings_form(Editor $editor) {
   +    '#type' => 'inline_template',
   

   Let's add @todo that reminds that we should convert these to use #type=>item after #3164524: Item elements are added to form state has been resolved

2. +++ b/core/modules/editor/editor.admin.inc
   @@ -106,10 +106,13 @@ function editor_image_upload_settings_form(Editor $editor) {
   +    '#template' => '<div class="form-item form--inline__separator"> × </div>',
   
   @@ -120,9 +123,11 @@ function editor_image_upload_settings_form(Editor $editor) {
   +    '#template' => '<div class="form-item form--inline__separator"> ' . t('pixels') . ' </div></div>',
   
   +++ b/core/modules/field_ui/src/Form/FieldStorageAddForm.php
   @@ -151,6 +151,9 @@ public function buildForm(array $form, FormStateInterface $form_state, $entity_t
   +          'class' => ['form--inline__separator'],
   
   +++ b/core/modules/image/src/Plugin/Field/FieldType/ImageItem.php
   @@ -211,16 +211,28 @@ public function fieldSettingsForm(array $form, FormStateInterface $form_state) {
   +        'class' => ['form--inline__separator'],
   ...
   +        'class' => ['form--inline__separator'],
   
   @@ -238,16 +250,28 @@ public function fieldSettingsForm(array $form, FormStateInterface $form_state) {
   +        'class' => ['form--inline__separator'],
   ...
   +        'class' => ['form--inline__separator'],
   

   Should we rename this class to form-item--inline-separator to be more consistent with BEM? Or maybe we should make it a new block level class to not be dependent on form-item which is defined elsewhere.

3. +++ b/core/themes/claro/css/components/form--prefix-suffix.pcss.css
   @@ -0,0 +1,177 @@
   + * Prefix and suffix border radii are different depending if they are next to or
   ...
   + * Remove border radii that are adjacent to a prefix and/or suffix.
   

   Nit: s/radii/radius

4. +++ b/core/themes/claro/css/components/form--prefix-suffix.pcss.css
   @@ -0,0 +1,177 @@
   +  .form-item__wrapper--stacked-prefix .form-element.form-element:focus {
   +    margin-top: 5px;
   +  }
   +  .form-item__wrapper--stacked-suffix .form-element.form-element:focus {
   +    margin-bottom: 5px;
   +  }
   

   Why is this only needed on IE 🤔

The changes look good to me. The block level class name makes sense, and the comment clears things up. Moving back to RTBC.

The patch does not apply anymore. I believe the CSS would need to be regenerated, etc. so not trying to hotfix it locally.

$ git apply --index 3082672-103.patch 
error: patch failed: core/themes/claro/css/base/variables.pcss.css:12
error: core/themes/claro/css/base/variables.pcss.css: patch does not apply

Reroll of #103. Also added minimumred to the dictionary to pass cspell tests.

+++ b/core/modules/editor/editor.admin.inc
@@ -106,10 +106,15 @@ function editor_image_upload_settings_form(Editor $editor) {
+  // @todo change #type to 'item' in https://drupal.org/node/3165290
+  $form['max_dimensions']['ex'] = [
+    '#type' => 'inline_template',
+    '#template' => '<div class="form-item form-inline-separator"> × </div>',
+  ];

+++ b/core/modules/image/src/Plugin/Field/FieldType/ImageItem.php
@@ -211,16 +211,28 @@ public function fieldSettingsForm(array $form, FormStateInterface $form_state) {
+    $element['max_resolution']['ex'] = [
+      '#type' => 'item',
+      '#markup' => ' × ',
+      '#wrapper_attributes' => [
+        'class' => ['form-inline-separator'],
+      ],
+    ];

It's interesting that we're using inline template in one place and item type in another. How come we're not waiting for #3164524: Item elements are added to form state to use item everywhere?

I believe I recommended using inline templates as a work around for #3164524: Item elements are added to form state in #73. While it is not ideal I thought it could be acceptable. However, now that I'm looking at it again, I'm a bit concerned of using this work around given that changing to type item could have BC implications.

That sounds like at least needs discussion then.

Besides #108, we should probably add some test coverage for the JavaScript added here.

Hi, I just created a merge request with the latest patch (#103) to help with the review process. The changes are still mergeable (no conflicts with base branch) at this point.

• Code changes: https://git.drupalcode.org/issue/drupal-3082672/-/commit/4b6021303ebddfa...
• Tugboat preview: https://mr828-eqga78we1zfgckf0wcrdfkuknopjz9rz.tugboat.qa/

Thanks for making it easier to test @javi-er! Everything I've tested looks great but there's a JS issue on Firefox that might need some eyes: right now the width for the prefix is being calculated on the window resize and it's causing some issues. It can be reproduced at /admin/structure/types/manage/page/fields/add-field when the prefix is triggered changing the machine name: the width is only calculated when the window is resized.

Here's a recording of the behavior:

https://www.drupal.org/files/issues/2021-06-22/prefix.mp4

@ckrina I took a look and the width is actually calculated both on windows load and resize, the issue is that it should also be calculated again when a field becomes visible since the .visually-hidden class in the parent sets the width and height of that container to 1px which wrecks it.

To solve this, I added a listener for class changes on the parent, which is where the .visually-hidden class is located.
It will actually recalculate widths on any class changes in the parent to cover for any other future cases.

Another alternative was using drupalViewportOffsetChange event, which probably is an overkill since it will recalculate widths with any change, for instance if a fieldset is expanded.

I also changed this line https://git.drupalcode.org/project/drupal/-/merge_requests/828#note_30422 since it was throwing an error in the case of a CK Editor field with a prefix.

Thanks @javi-er!! I've reviewed it with modern browsers (Firefox, Chrome and Safari) and it works great but... IE11 not, sorry. The form to edit the label is not properly working and the label appears twice:

@lauriii mentioned on Slack that we have tried to support IE 11 the same way as any other browser but it might not make sense anymore given that we are dropping support for IE 11 in Drupal 10, so something along the lines of making it usable would make sense for him.

But the problem is that we end up with one extra label that makes the form confusing. This is how it should be:

So I'd say we should try to hide that extra label on IE11.

Apart from that, everything looks great. Here are some screenshots:

Tagging for Design4Drupal 2021. Contributions are Friday, July 22
https://design4drupal.org/

Correcting tag Design4Drupal2021

Rebased to 9.4.x

I rebased this to 9.4.x and I'm not seeing the issues on Internet Explorer 11 in my local, can you confirm if it's still happening? Screenshots below.

Thanks @javi-er! I've checked the commit and the color changes should be adapted to the new Gray scale from #3154539: Implement new Gray scale on Claro. So this needs some color changes now.

But on the other side you're right, I don't see that issue anymore on IE.

@ckrina great! I just updated the colors to adjust to the new grayscale, also as part of this ticket --color-minimumred is added as well.

Thanks @javi-er! On a design perspective this looks great!

I've taken a look into the code and I've found a few things, so I've left a few comments on the MR.

Also, I've found a place that is still not looking good, mentioned already in comment #90: /admin/structure/views/view/comment. See in Seven:

While in Claro:

I've updated the testing instructions too.

@ckrina hi! I addressed your comments in the MR.

Regarding the view page path prefix issue, it seems to be an issue with Views actually, since it's adding some HTML to the prefix without checking if there is a value, see: https://git.drupalcode.org/project/drupal/-/blob/9.4.x/core/modules/view...
which ends up with an empty prefix with just a "‎" marker on it. Although the problem seems to be that in that line, the site URL should be placed. In any case, this should be addressed in a separate ticket.

Looks like the JavaScript needs to be recompiled

$ cross-env BABEL_ENV=legacy node ./scripts/js/babel-es6-build.js --check --file /var/www/html/core/themes/claro/js/prefix-suffix.es6.js
[18:18:28] '/var/www/html/core/themes/claro/js/prefix-suffix.es6.js' is being checked.
[18:18:28] '/var/www/html/core/themes/claro/js/prefix-suffix.es6.js' is not updated.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Recompiled the JavaScript file to address #137

Looks like we also need to recompile the CSS. It was probably like that before, but I just saw the one failure and didn't look further. Sorry!

 yarn run v1.22.17
$ node ./scripts/css/postcss-build.js --check --file /var/www/html/core/themes/claro/css/components/form.pcss.css
[20:35:27] '/var/www/html/core/themes/claro/css/components/form.pcss.css' is being checked.
[20:35:27] '/var/www/html/core/themes/claro/css/components/form.pcss.css' is not updated.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
STYLELINT: core/themes/claro/css/components/form.pcss.css passed
 

@mherchel no problem :)

Recomplied the css files.

I can no longer replicate the issue on 9.4.x on the site information form, but I can on the image toolkit settings. Regardless, this design is a nice improvement!

To review the testing steps (macOS Safari 15, 560px width):

Passed

• Visit /admin/config/system/site-information and verify the Default front page field.
• Test it working with the focus design (using the keyboard to navigate to this field, for example).
• Visit /admin/config/media/image-toolkit and verify the JPEG quality field.
• Navigate to /admin/structure/types/manage/page/fields and start adding a field. Before saving it, edit the machine name.The preffix "field" should look like a preffix.
• Test the focus working fine with the error.
• Add several combinations of Number fields with Prefix and suffix, and multiple fields too.

Failed

• Enter a wrong machine name (like add and space in the middle) and verify the error looks as in the designs.
  • This doesn't look bad but certainly doesn't match the figma designs. There's too much spacing, and there's no inline error text.
  • 
• Visit /admin/structure/views/view/comment and click on edit Path under "Page settings". The field path on the dialog should look OK (no prefix).
  • This is not fixed yet
  • 
• Visit /user/1/edit and edit the Password field. The confirm password field shouldn't be visible until a password is entered, and the input and strength indicator shouldn't be too wide. (Per comment #66).
  • This is not fixed yet at >616px
• New bug: If I change the width while a collapsed fieldset is closed, and then open the collapsed fieldset, the prefix does not get restyled. For example, collapse "Front page" in Basic site settings, resize, and then open it again. I confirmed this in both Safari and Firefox.

Needs work for #142
@deviantintegral, thanks for the detailed review.

I reviewed the PHP and JS side of things. Very minor notes, that are of a "take it or leave it" variety. Nice work so far!

Regarding this comment from @deviantintegral for one of the issues:

Visit /admin/structure/views/view/comment and click on edit Path under "Page settings". The field path on the dialog should look OK (no prefix).

I pointed above that it seems to be an issue with Views actually, since it's adding some HTML to the prefix without checking if there is a value, see: https://git.drupalcode.org/project/drupal/-/blob/9.4.x/core/modules/view...
which ends up with an empty prefix with just a "‎" entity on it. (Although the problem seems to be that Url::fromRoute('<none>', [], ['absolute' => TRUE])->toString() it's returning an empty string). In any case, should this be addressed in a separate ticket for Views and not for Claro?

Also regarding this point on comment #142:

Enter a wrong machine name (like add and space in the middle) and verify the error looks as in the designs.
This doesn't look bad but certainly doesn't match the figma designs. There's too much spacing, and there's no inline error text.

Isn't this also a separate issue? there are two problems here but none seems to be on the scope of the prefix and suffix redesign:

1. The spacing between the field title and input is indeed bigger than the Figma design, but this is also happening in non-prefixed fields like the one immediately above (Label)
2. Errors aren't displayed inline but at the top, shouldn't this be done as a separate ticket for moving all error messages inline?

Continuing with points mentioned in #142:

Visit /user/1/edit and edit the Password field. The confirm password field shouldn't be visible until a password is entered, and the input and strength indicator shouldn't be too wide. (Per comment #66).
This is not fixed yet at >616px

I couldn't reproduce this, in my local the password confirm field is showing up after I enter a password, also in any case isn't this too a separate issue than suffix and prefix redesign?

Regarding the last point on #142:

New bug: If I change the width while a collapsed fieldset is closed, and then open the collapsed fieldset, the prefix does not get restyled. For example, collapse "Front page" in Basic site settings, resize, and then open it again. I confirmed this in both Safari and Firefox.

This was addressed in the merge request, but it was incorrect. I replaced MutationObserver with IntersectionObserver so it looks for actual visibility changes in the element instead of class changes in the wrapper parent.

CI checks are passing for me locally. There's been ckeditor changes in 9.4.x, let's see if merging clears them up.

I addressed the last two comments in the MR, I'm moving this to "needs review" since the errors in the tests doesn't seems to be related to these changes, please move it back to "needs work" otherwise.

Moving to Need work because of the test failures.

I've pushed up a fix for the kernel test, and updated against 9.4.x.

For the remaining javascript failures, I have got as far as replicating the issue. It looks like the

form-item__affix--stacked

(and the corresponding suffix) classes are not being applied to the form:

I likely won't get more time this week to dive into the actual fix for it, so someone else is welcome to pick this up.

https://git.drupalcode.org/project/drupal/-/merge_requests/828/diffs?com... should fix the above test failure 🤞.

Tests passed, and from my perspective all of the review notes I left are resolved. It looks like I don't have permission to actually mark them resolved in GitLab.

Thanks @deviantintegral ! I just marked all comments as resolved in the MR.

Moving this to RTBTC in hope of move it forward, since all the issues that were found are addressed now.

Thanks for the excellent work on this @javi-er. I did a followup review at the request of @lauriii, and found a couple issues above.

In addition to those:

There's a prefix in front of the views path. Is this intentional?

RTL styling isn't complete

It's looking really good, though. If I have time later this weekend, I'm going to continue to look through the code (I really haven't yet) and maybe push up some fixes.

Thanks @mherchel! I fixed the two issues you noticed in the MR.

Regarding the empty prefix you noticed in front of the Views path, I think this is a bug that needs to be addressed as a Views issue actually, see comment #146 above.