0e920ce3f4
With the current docs directory setup, I'm making too many mistakes and have to manually address path changes and directory moves on deploy. This makes for a frustrating experience developing locally and shipping releases. With this PR, we're basically back to the same setup from v3—duplicating the dist directory into our docs directory. Not the most ideal, but very straightforward for me as the release manager.
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.
{% capture 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.
{% capture example %}
Checkboxes and radios
Place any checkbox or radio option within an input group's addon instead of text.
{% capture example %}
Multiple inputs
While multiple <input>s are supported visually, validation styles are only available for input groups with a single <input>.
{% capture example %}
Multiple addons
Multiple add-ons are supported and can be mixed with checkbox and radio input versions.
{% capture example %}
Button addons
{% capture example %}
Buttons with dropdowns
{% capture example %}
{% endcapture %} {% include example.html content=example %}Segmented buttons
{% capture example %}
Custom forms
Input groups include support for custom selects and custom file inputs. Browser default versions of these are not supported.
Custom select
{% capture example %}
Custom file input
{% capture example %}
Accessibility
Screen readers will have trouble with your forms if you don't include a label for every input. For these input groups, ensure that any additional label or functionality is conveyed to assistive technologies.
The exact technique to be used (<label> elements hidden using the .sr-only class, or use of the aria-label and aria-labelledby attributes, possibly in combination with aria-describedby) and what additional information will need to be conveyed will vary depending on the exact type of interface widget you're implementing. The examples in this section provide a few suggested, case-specific approaches.