* Rewrite colored links to use color property again instead of --bs-link-color-rgb value because nav links and more do not set --bs-link-color-rgb
* Update bundlewatch
* Document it
Co-authored-by: Julien Déramond <juderamond@gmail.com>
* Docs: replace twbs/bootstrap-npm-starter by twbs/examples/tree/main/icons-font
* Revamp starter template to use new .icon-link, fix Bootstrap icon and text at top
* Remove extra CSS file
* Change links to twbs/examples
* Fix icon name
* Adjust icon link offset to more reasonable and scaling distance
Co-authored-by: Mark Otto <markdotto@gmail.com>
* Add new link utilities, update colored link helpers
* Remove commented out code
* Fixes
* Remove examples changes
* Fixes and copy
* Fix icon-link instances on homepage
* Bump bundlewatch
* Fix node-sass issue for rgba() function bug
* More bundlewatch
* One more time after merge
* Add callout for a11y
* Hover and focus-visible
* Add a11y callouts
* Remove duplicate for now
* More code review feedback
* Docs: add explanation of the base `.btn` class
and a callout reminding authors to at least define some focus styling if they intend to use it "naked"
* Turn callout into a warning
* Add initial heading
* Tweak callout wording
* Add global variables for box-shadow focus rings
* Update instances of -btn-focus-box-shadow to use -ring-box-shadow, unless it's for buttons or inputs
* fix variable name
* Add CSS variables for global focus styling, document it
* Move to CSS vars section
* Update scss/_nav.scss
Co-authored-by: Gaël Poupard <ffoodd@users.noreply.github.com>
* Helper and utils
* Fix bundlewatch
* Change 'Focus ring' in sidebar so that the page can be visible
* Minor typo fix
* fix merge
* Revamp some more, improve docs
Co-authored-by: Gaël Poupard <ffoodd@users.noreply.github.com>
Co-authored-by: Julien Déramond <juderamond@gmail.com>
Co-authored-by: Patrick H. Lauke <redux@splintered.co.uk>
* Add .nav-underline modifier class
* Tweak sizing and spacing, add underline on hover
* Rebuild with Sass and CSS variables
* Document CSS vars
* Bump bundlewatch
It's not easy to otherwise correlate the examples with the relevant classes: you'd have to mentally count and correlate them. This obviates that need. Please see the image below to see the usefulness of the above.
Co-authored-by: Mark Otto <markdotto@gmail.com>
* Use aria-labelledby to associate form-text (helper) with input field when it contains mandatory info (e.g. data format)
* Example in input-group needs aria-describedby (or aria-labelledby) too
Co-authored-by: Mark Otto <markdotto@gmail.com>
* Update hero button color
* Fix link color on examples index
* Move .bd-btn-lg to docs buttons partial, move larger border-radius to that class so medium buttons don't look odd
* Undo the markup split
* Round padding up to whole number
* Instantiate/initialize all non-autoplaying carousels in docs pages
* Rewrite/reorganise carousel docs page
* start with static/non-autoplaying examples
* explicitly mention that carousels currently need to be manually initialized
* split out and explain autoplaying and the weird "autoplay after first interaction" behaviour, as well as the pause on hover/focus
* Add callout about autoplaying and accessibility
* Don't have the dark variant example autoplay
* Add "autoplaying" to cspell custom dictionary
* Tweal wording, move Page Visibility API to autoplay section
* Tweak explanation for methods, add line break in js code for consistency with last code block on the page
* Tweak method descriptions
* Tweak headings (plural "carousels")
* Move some paragraphs out of intro and into basic example, reword the nested and accessibility paragraph
* Tweak warning about `.active` slide
* Tweak callout wording
* Further prose tweaks
move the sentence about not double-initialising autoplaying carousels to the callout right at the top
instead of talking about `data-bs...` attributes, talk about the "option" instead, as authors may be setting these not via data attributes, but at instatiation time with options in the constructor
remove the incorrect statement about pausing when keyboard focus is in the carousel
* Instantiate/initialize all non-autoplaying carousels in docs pages
* Rewrite/reorganise carousel docs page
* start with static/non-autoplaying examples
* explicitly mention that carousels currently need to be manually initialized
* split out and explain autoplaying and the weird "autoplay after first interaction" behaviour, as well as the pause on hover/focus
* Add callout about autoplaying and accessibility
* Don't have the dark variant example autoplay
* Add "autoplaying" to cspell custom dictionary
* Tweal wording, move Page Visibility API to autoplay section
* Tweak explanation for methods, add line break in js code for consistency with last code block on the page
* Tweak method descriptions
* Tweak headings (plural "carousels")
* Move some paragraphs out of intro and into basic example, reword the nested and accessibility paragraph
* Tweak warning about `.active` slide
* Tweak callout wording
* Further prose tweaks
move the sentence about not double-initialising autoplaying carousels to the callout right at the top
instead of talking about `data-bs...` attributes, talk about the "option" instead, as authors may be setting these not via data attributes, but at instatiation time with options in the constructor
remove the incorrect statement about pausing when keyboard focus is in the carousel
* Fix relative link
* Update site/assets/js/snippets.js
Co-authored-by: GeoSot <geo.sotis@gmail.com>
* Fix snippet.js
* Tweak content organisation just a bit
Co-authored-by: GeoSot <geo.sotis@gmail.com>
Co-authored-by: Julien Déramond <juderamond@gmail.com>
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
Co-authored-by: Mark Otto <markdotto@gmail.com>
* Rework progress bar markup and styles
Logically moves the various `role` and `aria-` attributes to the `.progress` element itself, leaving the `.progress-bar` to be used purely for the visual presentation. This fixes the problem #36736 that in certain browser/AT combinations, zero-value/zero-width progress bars are completely ignored and not announced.
For multiple/stacked progress bars, this PR introduces a new wrapper and class `.progress-stacked`, to accommodate for the fact that with the more logical structure above, we need full `.progress` elements with child `.progress-bar` elements, and can't get away with the fudge we had before of having a single `.progress` with multiple `.progress-bar`s.
Note that the old markup structures still work with this change, so this could be considered a non-breaking change - though one we definitely want to highlight as it's more accessible (as it now guarantees that zero-value/zero-width progress bars, whether on their own or as part of a multi/stacked bar, are actually announced)
* Add a note about progress bar change in migration guide
* Add notes with old markup examples and explanation
* Fix bundlewatch
* Update site/content/docs/5.2/components/progress.md
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
* Reintroduce deleted styles
Turns out they're needed for correct positioning of text inside progress bar
* Move changes in markup to Migrationg guide, link to that from top of progress page, rewrite some content
* Fix typo in callout
* Clarify "Sizing" section
* Remove redundant "now"
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
Co-authored-by: Julien Déramond <juderamond@gmail.com>
Co-authored-by: Mark Otto <markdotto@gmail.com>
Co-authored-by: Mark Otto <markd.otto@gmail.com>
These classes have existed since 5.1 but weren't previously documented.
Specifically:
* .text-black
* .bg-black
* .bg-black.bg-gradient
Co-authored-by: Mark Otto <markd.otto@gmail.com>
