Problem/Motivation

We need to take a step back and look at how forms looks when they are rendered, we have old markup still hanging & generally it would be a good time to look at it with fresh eyes.

e.g: search field:

<form action="/search/node" method="get" id="search-block-form" accept-charset="UTF-8" data-drupal-form-fields="edit-keys,edit-submit">
<div class="form-item form-type-search form-item-keys form-no-label">
  <label for="edit-keys" class="visually-hidden">Search</label>
  <input title="Enter the terms you wish to search for." type="search" id="edit-keys" name="keys" value="" size="15" maxlength="128" class="form-search">
</div>
<div class="form-actions form-wrapper" id="edit-actions">
  <input type="submit" id="edit-submit" name="" value="Search" class="button form-submit">
</div>
</form>

Problems:
We have a bit of leftovers from the long time ago

wrapper:
<div class="form-item form-type-search form-item-keys form-no-label">
* .form-item could be adressed instead as form > div (or be .form__item)
.form-type-search Fair enough describes which type form is
.form-no-label Describes if there's a label, but what is the use case for this?
.form-item-keys huh?
.form-search ok yes we got its a search - but we got that earlier a repeat from earlier

the field
<input title="Enter the terms you wish to search for." type="search" id="edit-keys" name="keys" value="" size="15" maxlength="128" class="form-search">

The id is connected to the label, so it must be there.

size are there any reason to have that ? its still part of html5, but imho smells of html4 / lets write markup that have inline styling inside of it. We have CSS to take care of that today and if there's not a width set to it, it gets to be default 20 wide.

.form-search this is already defined in the type and can be selected with input[type="search"] instead of adding in a custom class

Proposed resolution

as an example with the search field

<form action="/search/node" method="get" id="search-block-form"  accept-charset="UTF-8" data-drupal-form-fields="edit-keys,edit-submit">
<div class="form-type__search>
  <label for="edit-keys" class="visually-hidden">Search</label>
  <input title="Enter the terms you wish to search for." type="search" id="edit-keys" name="keys" value="">
  <input title="Enter the terms you wish to search for." type="search" id="edit-keys" name="keys" value="" maxlength="128">
</div>
<div class="form__actions>
  <input type="submit" name="" value="Search" class="button button--submit">
</div>

</form>

default classname would then be:

form > div / form__item { ... }
.form-type__search{ ... }
.form-type__search label{ ... }
input[type="search"] {...}
.form__actions{...}
.button / .button--submit{...}

That should make the overview and ease of reading forms quicker & IF a theme need more classnames to describe its easy to add in as needed (as we have agreed upon in the way points).

Remaining tasks

User interface changes

API changes

Comments

mortendk’s picture

Issue summary: View changes
mortendk’s picture

Issue summary: View changes
mortendk’s picture

Issue summary: View changes
mortendk’s picture

Issue summary: View changes
mortendk’s picture

updated the dreammarkup a bit to have bem naming etc

mortendk’s picture

gasp looking at input template it really needs some love

input.html.twig:

<input{{ attributes }} />{{ children }}

looks like we need to push some variables to the template as well to make it easy for a themer to change this, even if we dont agree on changing and keep it status quo

mortendk’s picture

Issue summary: View changes
mortendk’s picture

Issue summary: View changes
mortendk’s picture

else the dirty solution would be to do

input.html.twig

<input{{ attributes|without('size', 'class') }} />
{{ children }}

... i might be stupid but i cant find where the class gets generated :/

edit: they are in classes like core/lib/Drupal/Core/Render/Element/(Actions|Button|Details|File|TextField) etc.

lauriii’s picture

Title: streamlining form markup & css classnames for a better world » Form markup & CSS classname cleanup
Issue summary: View changes
mortendk’s picture

LewisNyman’s picture

form > div
Our CSS standards discourage the use of elements in selectors, and selectors that are overly reliant on the HTML structure. I can go into more detail/post some links if you want.

form__item
I actually think I prefer form-item to these alternatives, it means we can do stuff like form-item--search

.form-type__search
I prefer .form-item--search, see above

.form-type__search label
I'm thinking form-item__label, what do you think?

button--submit
I have no idea what use this class is, is this used for JS in some situations? This isn't a 'style' of button, it just describes what a form does. I'd be happy to kill it.

.form__actions
I don't know what form-actions is used for, I've always given it the same styling/spacing as form-item in my themes. Do we need this?

LewisNyman’s picture

We need to cover the label display variants as well as form--inline: #2417111: Replace container-inline with form--inline to display forms horizontally.

mortendk’s picture

form > div oooh yup true, even that i might gonna get a heart attack if we have a <form class="form"> ;)
.form-item makes sense then
.form-item__labelmakes perfect sense

form__actions - wrapper for the submit buttons normally located at the bottom of a node, my guess is this is legacy stuff thats where to make sure you could wrap the submit, cancel, delete buttons.

The biggest wtf i captured here was actually how hard it is to modify the <input> classnames as its all generated deep down in drupal somewhere, i would suggest that we get as much as this class generating out and into the input.twig.html file

mortendk’s picture

...also the inline forms as well

Should we do a codepen / gist somewhere and begin to hammer in markup / classname structure for all of forms ?
in that way we can get an overview of whats actually going on

edit: a codepen so we can hammer on the structure http://codepen.io/mortendk/pen/xGrKLb?editors=110

znerol’s picture

Coming over from #2503239: Consider using <label><input></input></label> instead of <label for="foo"></label>, note that for checkboxes and options the nested approach seems to be favorable because it is in fact easier to style (<label><input></input> somewhat lengthy label for a checkbox which might span more than one line in some cases</label>). E.g. bootstrap expects the markup that way.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Ivan Berezhnov’s picture

Issue tags: +CSKyiv18

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.