b46f05a948
This commit includes all the needed workarounds and most changes from the main branch for everything to work, like: * removing empty lines in raw HTML that break output * read .browserslistrc, CSS variables from disk instead of duplicating it * using Hugo mounts * using Hugo for the docs CSS/JS * move ToC Sass code to a separate file while adapting it for Hugo Thus, this patch makes our npm scripts faster since lint runs on one step and there's no separate docs assets processing.
14 KiB
| layout | title | description | group | toc |
|---|---|---|---|---|
| docs | Input group | Easily extend form controls by adding text, buttons, or button groups on either side of textual inputs, custom selects, and custom file inputs. | components | true |
Basic example
Place one add-on or button on either side of an input. You may also place one on both sides of an input. Remember to place <label>s outside the input group.
{{< example >}}
Wrapping
Input groups wrap by default via flex-wrap: wrap in order to accommodate custom form field validation within an input group. You may disable this with .flex-nowrap.
{{< example >}}
Sizing
Add the relative form sizing classes to the .input-group itself and contents within will automatically resize—no need for repeating the form control size classes on each element.
Sizing on the individual input group elements isn't supported.
{{< example >}}
Checkboxes and radios
Place any checkbox or radio option within an input group's addon instead of text.
{{< example >}}
Multiple inputs
While multiple <input>s are supported visually, validation styles are only available for input groups with a single <input>.
{{< example >}}
Multiple addons
Multiple add-ons are supported and can be mixed with checkbox and radio input versions.
{{< example >}}
Button addons
{{< example >}}
Buttons with dropdowns
{{< example >}}
{{< /example >}}Segmented buttons
{{< example >}}
Custom forms
Input groups include support for custom selects and custom file inputs. Browser default versions of these are not supported.
Custom select
{{< example >}}
Custom file input
{{< example >}}
Accessibility
Ensure that all form controls have an appropriate accessible name so that their purpose can be conveyed to users of assistive technologies. The simplest way to achieve this is to use a <label> element, or—in the case of buttons—to include sufficiently descriptive text as part of the <button>...</button> content.
For situations where it's not possible to include a visible <label> or appropriate text content, there are alternative ways of still providing an accessible name, such as:
<label>elements hidden using the.sr-onlyclass- Pointing to an existing element that can act as a label using
aria-labelledby - Providing a
titleattribute - Explicitly setting the accessible name on an element using
aria-label
If none of these are present, assistive technologies may resort to using the placeholder attribute as a fallback for the accessible name on <input> and <textarea> elements. The examples in this section provide a few suggested, case-specific approaches.
While using visually hidden content (.sr-only, aria-label, and even placeholder content, which disappears once a form field has content) will benefit assistive technology users, a lack of visible label text may still be problematic for certain users. Some form of visible label is generally the best approach, both for accessibility and usability.