Design guidelines: Form and form control #5047
Conversation
Adds a new "Best practices" section with a "Menu toggles and dropdowns in a form" subsection, documenting the use of the pf-m-form modifier and its effect on border radius across themes. Includes a do/don't example image.
- Replace design guidelines images for form, form-control, checkbox, radio, and text-input - Update spacing references in form design guidelines to use token values (--pf-t--global--spacer--lg, --pf-t--global--spacer--md)
Swaps PNG placeholders for actual SVG files across form, form-control, checkbox, radio, and text-input design guidelines to fix blurry images. Updates markdown references to match new SVG filenames.
| ## Usage | ||
| While form controls are useful in providing feedback on user input, they don't need to be implemented for every input instance. Only use form controls when it is essential to convey information to the user. For example, if any string is valid for a text input, or any selection in a list is acceptable, form controls are not necessary. | ||
|
|
||
| Apply the `pf-m-form` modifier to all dropdowns and menu toggles used in a form. The `.pf-m-form` class modifies the menu toggle's border radius to match other form elements. Read more on form controls in the [Form guidelines](/components/forms/form/design-guidelines). |
There was a problem hiding this comment.
@nicolethoen @kmcfaul @mcoker this makes sense to me but do we need to mention props on the react components or is the CSS enough?
|  | ||
| </div> | ||
|
|
||
| In the default PatternFly theme, form elements use `--pf-t--global--border--radius--control--form-element` (6px) border radius token. In the [Felt theme](/foundations-and-styles/theming#project-felt-theme), form elements, including input fields, menu toggles, and dropdowns, continue to use the same `--pf-t--global--border--radius--control--form-element` (6px) token, while other non-control components use `--pf-t--global--border--radius--control--default`. Using the `pf-m-form` class ensures that your form elements and menu toggle always match the border radius of the surrounding form fields, regardless of theme. |
andrew-ronaldson
left a comment
There was a problem hiding this comment.
Looks good to me but waiting on feedback about the react props.
mcoker
left a comment
There was a problem hiding this comment.
Left some comments, some are pretty nitpicky so feel free to pick and choose what you think is worth updating. Nothing here is blocking.
One thing though - it looks like this PR is adding a .png file for most/all of the SVGs - was that intended to be checked in? The images on the site are all still using the .svg - none of the markdown docs pages were updated to reference the new .png files.
|
|
||
| <div class="ws-docs-content-img"> | ||
|  | ||
|  |
There was a problem hiding this comment.
Should you remove the "Save changes" button from the one with switches?
There was a problem hiding this comment.
no big deal but the form on the right has "Button" text for both buttons, and has more space than the form on the left. I would expect the link button text to be "Cancel" since that's what all of our examples use.
|  | ||
| </div> | ||
|
|
||
| You also have the option to use progressive disclosure by nesting other controls underneath a checkbox. The nested options would be enabled or disabled when the user selects or deselects a checkbox. |
There was a problem hiding this comment.
In the form docs for progressive disclosure, we use the language "hide and show", which I think is more clear than enabled/disabled since enable/disable has special meaning when it comes to form fields.
| You also have the option to use progressive disclosure by nesting other controls underneath a checkbox. The nested options would be enabled or disabled when the user selects or deselects a checkbox. | |
| You also have the option to use progressive disclosure by nesting other controls underneath a checkbox. The nested options would be shown or hidden when the user selects or deselects a checkbox. |
There was a problem hiding this comment.
FWIW the exclamation-circle in the right one is kinda floating in the middle of the input
|
|
||
| ### General spacing | ||
| Always add 24px of spacing underneath each form input. If a form input includes helper text, this 24px spacing should start below the helper text. Spacing between data inputs like checkboxes and radio buttons should also be 24px when on the same line or stacked on one another. For more spacing information, consult the [PatternFly spacer guidelines](/foundations-and-styles/spacers#considering-line-height-and-padding). | ||
| Add `--pf-t--global--spacer--lg` (24px) of spacing below each form input. If a form input includes helper text, this spacing should start below the helper text. Spacing between data inputs like checkboxes and radio buttons should also be `--pf-t--global--spacer--lg` (24px) when on the same line or stacked on one another. For more spacing information, see the [PatternFly spacer guidelines](/foundations-and-styles/spacers#considering-line-height-and-padding). |
There was a problem hiding this comment.
FWIW we use --pf-t--global--spacer--gap--group-to-group--vertical--default between form groups.
IMO the image is a little weird, too
- It shows padding around the form, which probably shouldn't be there (it isn't part of our form)
- It calls out the xl/32px spacer between the last form group and the submit button row but that isn't in this paragraph
- Also the image refers to that spacer as "2xl" when the code uses "xl"
- If we do use the more semantic spacer (
gap--group-to-group...) in the docs, I wonder if we should update the image, too.
| ### Button spacing | ||
|
|
||
| Place submit or cancel buttons on the bottom left of a form, left-aligned with all form fields. Buttons should be placed 16px apart in all contexts. Buttons for actions other than submitting or canceling the form may be placed elsewhere within a form depending on your use case. | ||
| Place submit or cancel buttons on the bottom left of a form, left-aligned with all form fields. Buttons should be spaced using `--pf-t--global--spacer--md` (16px) in all contexts. Buttons for actions other than submitting or canceling the form may be placed elsewhere within a form depending on your use case. |
There was a problem hiding this comment.
FWIW we use --pf-t--global--spacer--gap--action-to-action--default in the code (in our action list component).
|
|
||
| To ensure your forms are consistent, maintainable, and adaptable across different themes, we recommend following these best practices. | ||
|
|
||
| ### Menu toggles and dropdowns in a form |
There was a problem hiding this comment.
If this is clear for designers, I'm sure it's good, but to me the word "dropdowns" reads like it's something separate from a menu toggle. I would probably just say menu toggles.
|  | ||
| </div> | ||
|
|
||
| In the default PatternFly theme, form elements use `--pf-t--global--border--radius--control--form-element` (6px) border radius token. In the [Felt theme](/foundations-and-styles/theming#project-felt-theme), form elements, including input fields, menu toggles, and dropdowns, continue to use the same `--pf-t--global--border--radius--control--form-element` (6px) token, while other non-control components use `--pf-t--global--border--radius--control--default`. Using the `pf-m-form` class ensures that your form elements and menu toggle always match the border radius of the surrounding form fields, regardless of theme. |
There was a problem hiding this comment.
Nit, but above you used the period conditionally to refer to the "pf-m-form modifier" and ".pf-m-form class", but here you're referring to the class so I would use the period.
| In the default PatternFly theme, form elements use `--pf-t--global--border--radius--control--form-element` (6px) border radius token. In the [Felt theme](/foundations-and-styles/theming#project-felt-theme), form elements, including input fields, menu toggles, and dropdowns, continue to use the same `--pf-t--global--border--radius--control--form-element` (6px) token, while other non-control components use `--pf-t--global--border--radius--control--default`. Using the `pf-m-form` class ensures that your form elements and menu toggle always match the border radius of the surrounding form fields, regardless of theme. | |
| In the default PatternFly theme, form elements use `--pf-t--global--border--radius--control--form-element` (6px) border radius token. In the [Felt theme](/foundations-and-styles/theming#project-felt-theme), form elements, including input fields, menu toggles, and dropdowns, continue to use the same `--pf-t--global--border--radius--control--form-element` (6px) token, while other non-control components use `--pf-t--global--border--radius--control--default`. Using the `.pf-m-form` class ensures that your form elements and menu toggles always match the border radius of the surrounding form fields, regardless of theme. |


closes #5052
Changes
pf-m-formmodifierpf-m-formusage note to the form-control design guidelines--pf-t--global--spacer--lg,--pf-t--global--spacer--md)