* Manually backport 32630
Dynamic tabs: use buttons rather than links
* Tweak unit test
* Tweak unit tests
* More tweakage
* show() should also bail if `disabled` attribute is set
* Tweak tests
* Simplify test for relatedTarget
* Temporarily remove problematic test
(as i can't get local tests to run just noww)
* Revert previous
* test: fix broken test cases for tab.js
* test: fix role=tablist invalid on nav element
* test: prefer <div/> over <div></div>
* Manually backport 32630
Dynamic tabs: use buttons rather than links
* test: fix broken test cases for tab.js
* Fixes
* Remove and ignore lock file
Co-authored-by: alpadev <alpa.muc@gmail.com>
Co-authored-by: Mark Otto <markd.otto@gmail.com>
Co-authored-by: Mark Otto <markdotto@gmail.com>
manual backport of #34886
per https://www.w3.org/TR/html-aria/#docconformance
> It is NOT RECOMMENDED to use `aria-disabled="true"` on an `a` element with an `href` attribute.
>
>NOTE
>If a link needs to be "disabled", remove the `href` attribute.
This PR removes the unnecessary `href="#"`, `tabindex="-1"`, and `aria-disabled="true"` from disabled links in both docs pages and examples. `aria-disabled="true"` *is* kept for disabled link-based buttons (that have `role="button"`) as there it's appropriate to use (you *want* to convey to assistive technologies that this thing you're claiming is a button is also disabled at the moment)
Further, the PR extends the "Link functionality caveat" to show the "proper" way (removing `href` and adding `.disabled` class only) to disable a link, but then explains what to do if that's not possible (and then keeps an example with all the traditional `href="#" tabindex="-1" aria-disabled="true"`, but explains clearly that it's not ideal). Same sort of explanation is also added to the pointer event utilities page
`aria-haspopup="true"` is really intended to signal that an ARIA `menu` will be opened on activation. as a result, some assistive technologies will announce controls with `aria-haspopup="true"` as a menu or menu item (e.g. JAWS and NVDA).
In addition, `aria-haspopup` seems to trigger a bug in Edge/Narrator where the `aria-expanded` state is not correctly announced at the moment when `aria-haspopup` is present.
This now makes the dropdown button more like a generic disclosure widget control - see also https://www.w3.org/TR/wai-aria-practices-1.2/examples/disclosure/disclosure-navigation.html01
* Add a callout for the sanitizer in popovers and tooltips
* Add second reference to sanitizer in the options
Co-authored-by: XhmikosR <xhmikosr@gmail.com>
* Backport #32037
Add `.navbar-nav-scroll` for vertical scrolling of navbar content
* drop the css var for a Sass css
Co-authored-by: Mark Otto <markdotto@gmail.com>
* Backport of changes to v5 docs that updated and clarified information about the Sass compiler used and the minimum rounding precision we recommend with it.
Co-authored-by: Mark Otto <otto@github.com>
Co-authored-by: XhmikosR <xhmikosr@gmail.com>
They're links, acting as links. Just because they're styled as buttons visually (as is often the case for "Call to action" (CTA) links) doesn't mean they need/get `role="button"`
While technically it still works, we're already saying authors shouldn't do it later on, and we removed any examples of this. This was a straggler.
Co-authored-by: XhmikosR <xhmikosr@gmail.com>
* v4: Add an actual `data-touch="false"` example in the carousel docs
Backport of https://github.com/twbs/bootstrap/pull/32638
* Remove data-ride from example carousel
* Correct attribute table explanation and remove slide class from example
i believe the correct option is `slide` here, not `ride`.
the `if "carousel"` bit was rather unclear/confusing
* Edits...
sorry, trying to make sense of our quirky carousel stuff, it seems some illogical things have been there ever since
* Add data-interval to suppress autoplay
* Tweak carousel options formatting
* Update site/content/docs/4.5/components/carousel.md
Co-authored-by: Mark Otto <markd.otto@gmail.com>
* Tweak language
mostly based on @mdo's suggestion, but also adds the word "attribute" after `data-ride` for better flow/legibility
Co-authored-by: Mark Otto <markd.otto@gmail.com>
