| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
Remove sentence in docs that's no longer needed. Fixes #32082.
|
|
* Support floating labels on `.form-control-plaintext`
* Update floating-labels.md
* Apply suggestions from code review
Co-authored-by: XhmikosR <[email protected]>
Co-authored-by: Mark Otto <[email protected]>
|
|
* Add .form-check-reverse modifier class
* Update checks-radios.md
Co-authored-by: XhmikosR <[email protected]>
|
|
|
|
> You can disable every form element within a form with the `disabled` attribute on the `<form>`.
I really want to be mistaken, because this would be a very useful feature! But I don't believe it's true. I can't find anything about this on MDN Web Docs, and adding the `disabled` attribute to a `<form>` does nothing on any browser in my testing.
The `disabled` attribute on a `<fieldset>` does disable all descendant form controls – perhaps that's where the mixup has come from.
|
|
These variables are called $input-btn-*, the documentation was erroneously talking about $btn-input-*.
Co-authored-by: XhmikosR <[email protected]>
|
|
While it is understood that this is just an example, the visible text (label) of "Works with selects" and the `aria-label="Floating label select example"` created a [WCAG 2.5.3 Label in name](https://www.w3.org/WAI/WCAG21/quickref/#label-in-name) failure.
As the `aria-label` isn't necessary here since this `select` is already provided an accessible name by its `label` element, removing the unnecessary `aria-label` seems the best course of action as:
* removing it solves the WCAG issue
* it removes the potential implication to developers that they'd even _need_ an `aria-label` here, let alone indirectly suggesting that it's ok for the visible text and accessible name to be out of alignment
|
|
* docs: Add role="switch" to switches
* Tweak/expand explanation about assistive technologies
Co-authored-by: Patrick H. Lauke <[email protected]>
|
|
|
|
|
