'forms-inline' class should ensure all direct descendants are inline

Tagging Field UX as there's a good chance of future developments making greater use of inline form elements.

If there are backwards compatibility concerns with the solution as proposed that don't seem sufficiently addressed by stable, another option is to create a new class that has the proposed changes targeting direct descendants, but keep the current one working as is.

The CSS codes are available in the repository.

grep -r 'form--inline' core/themes/olivero

Addressed #17, attached interdiff for same. please review

Why are we adding a css folder to core?

/core/css/form--inline.css

I have updated the code in all themes instead of creating a single directory inside the core, as in patch #21. I have updated the patch and attached an interdiff for the same.

the issue, summary say Olivero theme but the above patch is for claro, demo_umami and starterkit_theme, looks summary needs to be updated:
Suggestion:

The 'forms-inline' class should ensure all direct descendants are inline within all the core themes provided namely: claro, olivero, demo_umami and starter kit

Checked the patch given on #23 apply cleanly and looks good to proceed

Could the issue summary be updated for what the target themes are please

Reread it and the issue summary mentions we should be done in all of core and since those are the themes should be fine.

index b5201a78c9..a230e0982f 100644
--- a/core/profiles/demo_umami/themes/umami/css/classy/components/inline-form.css

--- a/core/profiles/demo_umami/themes/umami/css/classy/components/inline-form.css
+++ b/core/profiles/demo_umami/themes/umami/css/classy/components/inline-form.css

index b5201a78c9..e762ff9682 100644
--- a/core/themes/claro/css/classy/components/inline-form.css

--- a/core/themes/claro/css/classy/components/inline-form.css
+++ b/core/themes/claro/css/classy/components/inline-form.css

At the moment these CSS files are in the classy directory because they are exact copies of Classy. However, not that we are modifying these, it is no longer the case. For that reason, we should move them outside the classy directory.

Addressed #28

+++ b/core/themes/claro/claro.libraries.yml
@@ -40,6 +40,7 @@ global-styling:
       css/components/form--select.css: {}
       css/components/help.css: {}
       css/components/image-preview.css: {}
+      css/components/inline-form.css: {}
       css/components/menus-and-lists.css: {}
       css/components/modules-page.css: {}
       css/components/node.css: {}

This looks good, but the library definition should also have its reference to css/classy/components/inline-form.css: {}
removed

Addressed #30

Since we are moving files can we update the issue summary please.

The last submitted patch, 29: 3232665-29.patch, failed testing. View results →

Thanks for the IS update.

The last submitted patch, 29: 3232665-29.patch, failed testing. View results →

The last submitted patch, 29: 3232665-29.patch, failed testing. View results →

I'm seeing some regressions with this change. It's probably worth checking all usages of .form--inline and making sure they continue to look OK.

The issue appears when the "Exposed form" is displayed in a block. During the display "Exposed form" in the block, the form--inline class adds on outer div instead form tag. so fixed the issue according to it and created a patch.

Probably best to disregard #40, but hopefully the feedback here helps you give it another shot @ravi kant

The issues reported in #38 are happening in the Claro theme

The change in #40 is being made to the Olivero theme. This would have no impact whatsoever.

In addition, the changes were made to form.css. Olivero and Claro changes need to be made to .pcss.css files, then the build process → creates the css files.

Nothing in #38 deals with views exposed forms so that's probably not the place to target. Also, screenshots of html isn't particularly helpful, but seeing how it appears as an actual styled page can be helpful.

Currently the issue summary explains this change should happen Olivero is doing it. #38 points out there are regressions. The issue summary should be updated to better explain why this is a beneficial change. If that is documented, we can better decide if making the actual potential-regression-causing change is worthwhile.