Consider adding form elements to the theme.json elements block

[MaggieCabrera]

What problem does this address?

A theme will want to have a specific design for its form elements that is consistent across blocks (be them core blocks or third-party). Ideally, if the user wants to alter this design, their changes should expand through all affected blocks from Global Styles, not just one by one (if I want my buttons to be red, I want ALL buttons on the site to be red, not just the button block).

Right now some of the blocks that have form elements don't let you style them or they do so very limitedly. Examples of these are the Search Block, the File Block and the Post comments form Block. The only way for a theme to make them consistent with each other is via CSS.

What is your proposed solution?

We could have buttons, inputs, textareas, labels, selects... be styled within styles.elements on theme.json and have the blocks using them use these styles as presets and in the future surface this in the Global Styles sidebar for the user to change too.

/cc @oandregal @mtias @youknowriad

[oandregal]

For context, a related conversation is https://github.com/WordPress/gutenberg/issues/34141#issuecomment-902178472

[oandregal]

These elements make sense to me as cross-block components.

The only bit I'm unsure about is the button: we already have a button block. Ideally, all complex blocks would use it as an inner block - that will solve the issue. I understand that's not always possible, though. If we create a button element, how would that interact with the styles in the button block? Say we have this:

{
  "styles": {
    "elements": {
      "button": {
        "color": {
          "text": "antiquewhite",
          "background": "coral"
        }
      }
    },
    "blocks": {
      "core/button": {
        "color": {
          "text": "deeppink"
        }
      }
    }
  }
}

What would be the expected CSS?

[MaggieCabrera]

The only bit I'm unsure about is the button: we already have a button block. Ideally, all complex blocks would use it as an inner block - that will solve the issue. I understand that's not always possible, though. If we create a button element, how would that interact with the styles in the button block?

I wish the button block could be used by other blocks as well, that way when the button block supports hover states, so will the rest of the blocks using it, right? As to the CSS on your example, I would expect it to be the same as the headings, where the styles defined for the block override the ones for the element.

[oandregal]

I'll let other people share their thoughts. It seems this could be useful, in my view. I'll have to see specific examples for the button, but that's something that can be explored in a specific PR with a theme that uses the core button and addresses buttons as elements.

[overclokk]

Also a link element could be a button (or at least styled like a button), so why not add a controller for the block to indicate a type of the element, the controller will add a css class to the block we can refer in the theme.json to apply the style, so we could have:

{
  "styles": {
    "types": {
      "button": {
        "color": {
          "text": "antiquewhite",
          "background": "coral"
        }
      }
    },
    "blocks": {
      "core/button": {
        "color": {
          "text": "deeppink"
        }
      }
    }
  }
}

A CSS class name could be something like is-type-button or has-type-button or wethever.

This way we only have one global CSS class name for all button types, button block, file block, comment form block and search block, and we can activate a type button also for link in the navbar, in the content and why not also for radio button, checkbox and input fields.

For nested element we can apply a few line of CSS to create a different design, let say for example for the search bar we want a design with "icon, input and button" grouped together.

This way we can create something similar to what the library like Bootstrap does.

[carolinan]

I believe that this has been solved for buttons? How can we move this forward and discuss the other form elements?

[MaggieCabrera]

I believe that this has been solved for buttons? How can we move this forward and discuss the other form elements?

I think no one has picked anything up, but I don't think there's any blockers besides wanting to work on it? Working on the input or labels would be great, it would give themers and users much better control over the search block as a whole. Also, when we upgrade the comments form to a proper block it would be great to have them all be made with elements from the start.

[mtias]

All form element need a lot more thinking before being considered for the elements API, including how they are going to be controlled, and how they are going to be leveraged by block authors.

[senadir]

I believe that this has been solved for buttons?

I'd love to see any docs around this?

[MaggieCabrera]

I believe that this has been solved for buttons?

I'd love to see any docs around this?

Elements are documented here

[dkjensen]

+1

[mikeritter]

This is holding me back.

I don't see a roadmap to keep this on track.

HTML Form elements

<input>
<label>
<select>
<textarea>
<button>
<fieldset>
<legend>
<datalist>
<output>
<option>
<optgroup>

Inputs?

<input type="button">
<input type="checkbox">
<input type="color">
<input type="date">
<input type="datetime-local">
<input type="email">
<input type="file">
<input type="hidden">
<input type="image">
<input type="month">
<input type="number">
<input type="password">
<input type="radio">
<input type="range">
<input type="reset">
<input type="search">
<input type="submit">
<input type="tel">
<input type="text">
<input type="time">
<input type="url">
<input type="week">

The select element

<label for="cars">Choose a car:</label>
<select id="cars" name="cars">
  <option value="volvo">Volvo</option>
  <option value="saab">Saab</option>
  <option value="fiat">Fiat</option>
  <option value="audi">Audi</option>
</select>

Fieldset

  <fieldset>
    <legend>Personalia:</legend>
    <label for="fname">First name:</label><br>
    <input type="text" id="fname" name="fname" value="John"><br>
    <label for="lname">Last name:</label><br>
    <input type="text" id="lname" name="lname" value="Doe"><br><br>
    <input type="submit" value="Submit">
  </fieldset>

Optgroup

<label for="cars">Choose a car:</label>
<select  name="cars" id="cars">
  <optgroup label="Swedish Cars">
    <option value="volvo">Volvo</option>
    <option value="saab">Saab</option>
  </optgroup>
  <optgroup label="German Cars">
    <option value="mercedes">Mercedes</option>
    <option value="audi">Audi</option>
  </optgroup>
</select>

[mikeritter]

I believe that this has been solved for buttons? How can we move this forward and discuss the other form elements?

I think no one has picked anything up, but I don't think there's any blockers besides wanting to work on it? Working on the input or labels would be great, it would give themers and users much better control over the search block as a whole. Also, when we upgrade the comments form to a proper block it would be great to have them all be made with elements from the start.

Suggested Pathway

1. Identify sensible default properties to override for general input element (i.e., user agent defaults, common properties, states)
2. Identify layout patterns for grouping label and input elements (ul, div, label)
3. Repeat 1 for label then apply wrapper style to label
4. Apply to Search block
5. Apply to Comments block

[mikeritter]

I just found the Jetpack Forms Block with much of this heavy lifting built in. Here is a link to the GitHub repo for Form block.

[scruffian]

I have an idea for this here: https://github.com/WordPress/gutenberg/pull/51337