Replace container-inline with form--inline to display forms horizontally.

Happy to start working on this.

Hi LewisNyman,

Looking through this issue and form--inline seems to be using float:left rather than display:inline (or inline block).

If we replace the container-inline with this in typical actions/operations forms (eg. comments update options) we are going to have some issues with alignment (see screenshot example). Should work fine with form inputs ofc.

Wouldn't it be preferable to use inline styling for these types of elements?

If not do we prefer to use container-inline for these situations or replace everything with form--inline?

Let me know what the preferred approach is and I will provide a patch for this.

Thanks,

Sure np.

I will patch using all form elements using form--inline (float:left) and we can tackle the ones that break after.

It is actually consistent every form where the float is with a select next to a submit button we have the issue. Form inputs and things like that the form--inline works ok.

I will work on the patch and we will take it from there.

Hi LewisNyman,

Attaching a patch for this.

It does not cover all of the instances of container-inline as they are many but it's a starting point.

I'm sure just this will raise a few issues by itself.

A couple of things to note are some paddings included in modules by default that seem to be dependent on the old display-inline style, so I updated them as well. Don't know if it is preferable to update them just in seven but it seems to me that by having specific values like paddings in the base styles will always cause issues like this.

Another thing is the fact that the form--inline style is floated, sometimes affects following elements. An example of this is the image settings in the image field configuration where the descriptions get floated together with the inputs putting the description aside the inputs, which screws up the layout. I have added a clear on the description to fix this for now.

Let me know your comments and I will continue working on the remaining instances meanwhile.

Cheers,

Ufff...

Okay, we should now have all instances identified and changed :)

From the previous patch I have also reverted style changes in module's CSS as I assume they will be cleaned up in another issue (interdiff attached).

We should be able to have an index of instances from the attached screenshots.

The only exception (not in screens) is one instance in views AddHandler.php. That basically shows a div with the fields you selected to add to a view and it completely breaks after changing the class to form--inline.

This should be a good starting point.

Where do you suggest we go from here?

Hey,

Here are the remaining urls:

/admin/config/regional/translate
node/%/edit
/node/preview/%/default
/admin/config/system/actions
/admin/content/comment
/admin/structure/types/manage/article/fields/node.article.field_image
/node/add/article (WYSIWYG image editor)
/node/add/%node-with-date-field

What's the next step?

Hi LewisNyman,

Cool stuff :)

Where do you propose we go from here?

Rerolling patch.

Marking for review.

Okay so it seems that the issue with the comments in:

/admin/content/comment — Incorrect spacing on desktop/mobile

Is due to the fact that it's not using the actions wrapper which according to form API:

"A wrapper element to group one or more buttons in a form. Use of the 'actions' element as an array key helps to ensure proper styling in themes and to enable other modules to properly alter a form's actions"

I am attaching the revised patch adding the wrapper in the CommentAdminOverview class

Hey,

The issue in the article is because the form--inline elements need to be cleared since we are now using floats.

I don't know what is your preferred method, overflow or pseudo element in the wrapper so I opted for the latter as it does not have the inconveniences of setting the overflow (hiding content if setting or scrollbar if setting auto).

Let me know what are your thoughts.

rerolling a #23 patch

Attaching rerolled patch.

Will look into fixing the above issues later tonight.

Hey guys,

Here goes the updated patch to address the issues raised in #24 and #25

I tried to make the changes as minimal as possible but it is possible there are side effects for the rule added in form.theme.css

Interdiff attached.

Hey,

First of all my bad on the form .field-add-more-submit, I thought I read it as inline (that's what you get for patching late night).

I have reverted the changes there and added the clearfix.

As for the margin-top I applied it in a specific rule .form--inline.form-actions and mobile seems to be working fine (see attached screen).

However, the fact is that this probably shouldn't be marked up like this.

If you look at other form actions (e.g content or comments) we have a form--inline wrapper and the form-items inside.

In this case though we have the form--inline in the form-actions element itself.

What you you propose we do here?

Attaching patch and interdiff from 31.

Changing to needs review.

Patch #33 does not work. Probably due other issue and bug resolving some files were changed and removed.

error: patch failed: core/modules/editor/src/Form/EditorImageDialog.php:147
error: core/modules/editor/src/Form/EditorImageDialog.php: patch does not apply
error: core/modules/system/css/components/inline-form.theme.css: No such file or directory

rerolled a patch.

Rerolled last patch, because it doesn't applied. Added fix for search form.

Fixed tabspace errors in #40

Probably, This should be move to 8.x.2 branch.

#41 rerolled.

here is the re-rolled patch.

I cannot reproduce the problem mentioned at #35.

I need to do something in specific in order to reproduce it?

@gnuget Issue that lewis has mentioned in #35 is reproducible below 1037px.

I tried to work on this using the patch #49 but it looked weird on my side, after of debugging I found out to some lines were missing from #33 so I made another re-roll from the original patch.

I attach the re-rolled patch and the interdiff between this one and 49.

I will continue working on this.

I just re-added the changes introduced by #40 for fixing the issue related to the search box.

And there was a similar problem in the search page, I fixed that one in this patch.

This is ready to be reviewed again.

This is blocking #2160621: Button spacing CSS is too fragile

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.