New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider adding form elements to the theme.json elements block #34198
Comments
For context, a related conversation is #34141 (comment) |
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? |
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. |
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. |
Also a {
"styles": {
"types": {
"button": {
"color": {
"text": "antiquewhite",
"background": "coral"
}
}
},
"blocks": {
"core/button": {
"color": {
"text": "deeppink"
}
}
}
}
} A CSS class name could be something like 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. |
I believe that this has been solved for buttons? |
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. |
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. |
I'd love to see any docs around this? |
Elements are documented here |
+1 |
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> |
Suggested Pathway
|
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. |
I have an idea for this here: #51337 |
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
The text was updated successfully, but these errors were encountered: