* WIP: Mention variables, mixins, and loops in docs
* Add Sass sections to component pages
* add sass docs for forms and content
* Update buttons.md
* Remove empty mixins sections
* Massive update to utilities and some consistency changes
Co-authored-by: XhmikosR <xhmikosr@gmail.com>
- Adds .mt-0 to the examples
- Zero-ing out universally for all of them like in #32896 would cause issues for those who include the input with visible label text, where the text and input would be misaligned
* v5: Promote floating labels example to component
- Adds new .form-floating
- Stubs out basics of a docs page
- Removes existing Example
* Update floating labels to support .form-select, make inputs and selects more consistent
- To do this, I made the .form-control and .form-select consistent in min-height vs height
- Removed some unused variables now
- Updated -color to be the -color because I don't know why this was any different before
- Update page to include some examples for layout, validation, and value
- Rewrite styles to not modify padding, but instead transform and opacity
* Streamline and bulletproof some things
- Apply some optimizations from code review
- Removed unecessary properties from the label
- Add some comments for what properties are required
- Move from fixed height for labels to height 100% so we can support textareas
- Improve docs a little bit, add ToC
* Move some values to variables, switch from scaling font-size to scale, update transforms
* Bring over changes from #30966 and add to them to tighten things up
* Delete the now unused example images
* Fix typo
* Allowlist the calc function
* Add transform-origin, update transform values
* Test out autofill fix
* Fix linter issue
* Mention it in the migration guide
* Bump bundlesize
* Add one more variable per review
* Shave .25rem off the height
Co-authored-by: XhmikosR <xhmikosr@gmail.com>
Remove the `markdownify` call, and instead rely on Hugo's proper syntax; `{{% callout %}}` when we want to the content to be processed as Markdown.
This allows for stuff like:
{{% callout info %}}
##### I'm an info callout!
```css
.foo {
color: #fff;
}
```
{{< example >}}
<div class="alert alert-warning alert-dismissible fade show" role="alert">
<strong>Holy guacamole!</strong> You should check in on some of those fields below.
<button type="button" class="btn-close" data-dismiss="alert" aria-label="Close"></button>
</div>
{{< /example >}}
{{% /callout %}}
* Add disabled state example to the .form-control page
* Document disabled attribute on select too
* Add disabled example for file input
Co-authored-by: XhmikosR <xhmikosr@gmail.com>
* Expand on disabled fieldsets and faked buttons
include further advice/information on how to disable faked buttons for keyboard/AT users
* Centralise accessible name advice in forms overview
seems odd to only mention (separately) label, aria-label etc in input-group and layout. the advice is just as pertinent in other sections like select. checks only skims over this.
moving this, in expanded form, into the overview section itself. adding a specific cross-reference (just because they are easily left with no accname at all) in the checks page.
* Change warning about accessibility, modify server-side example
- paradoxically, due to our current problems with validation (see #28414) and the fact that browsers seem to have improved in this area for the most part, it's now actually better to use browser-native validation
- added explicit `id` and `aria-describedby` association to at least the server-side form error messages, to show how it should be done properly, and expanded the prose for that explaining this.
* Replace `.sr-only` with `.visually-hidden` in new addition
* Copy edits for clarity in parenthetical
* Copy and formatting tweaks
- Wordsmithing here and there
- Turns some hyphens into em dashes
- Turns a long running comma separated list into an unordered list
- Rearranges some copy just a bit
Co-authored-by: Mark Otto <markd.otto@gmail.com>
"screen readers" is quite reductive, as there are other assistive technologies. content hidden this way is even announced by things like Alexa/Siri etc, so it's not so much just "screen readers".
in the long run, we may even consider changing the actual classnames (maybe `.visually-hidden` / `.visually-hidden-focusable`, though admittedly that's a bit verbose).
also includes a tiny tweak to layout.md to generalise the note about using `.sr-only`
* Keep checks/radio toggle buttons on topic
- give examples of the pure toggle checks and radios, without the button group class. show that these work fine without `.btn-group`, but still cross-reference it
- move the explanation from "Checkbox toggle buttons" directly to "Toggle buttons", as the mention of using button classes applies equally to the subsequent "Radio toggle buttons" and "Outlined styles" subsections.
* Expand button group description
as it's not just single line, but vertical as well
* Expand button group examples
- add more colour ... `.btn-secondary` is just dull and uninspiring
- new section to showcase "Checkbox and radio button groups"
- add a mixed styles example
- add an example of vertical radio button group
* Rename `sr-only`/`sr-only-focusable`
To be more representative of the fact that these are not necessarily "screen reader" specific, but actually apply to assistive technologies in general (and also things like Alexa/Siri/etc). Goes hand-in-hand with #31133
Co-authored-by: XhmikosR <xhmikosr@gmail.com>
* Docs: improve/expand button documentation
- since we're not doing the disabled cursor thing anymore anyway, remove confusing/unnecessary mention for link-based disabled buttons
- make the disabled toggle example using a link actually follow the preceding advice of also having `tabindex="-1"` and `aria-disabled="true"`
- tweak the link functionality callout to also still mention `aria-disabled` to reinforce the idea
- tweak toggle state description (not just `<button>`s, but also links etc...so just remove mention of `<button>` there; also reinforce accessibility aspect once more)
- add a new callout that cross-references checkbox-based toggles, and what the similarity/difference between them is
- add a matching cross-reference callout to the checkbox-based toggle buttons page
* Update link to now renamed checks-radios.md
* Docs: rename form checks page to "Checks / radios"
it's not immediately obvious that "checks" includes information about both checkboxes and radio buttons. while "checks / radios" is also still not perfect (as honestly even I didn't quite grok that "checks" meant checkboxes), it should make it slightly more obvious nonetheless
