According to the docs, you just need to apply the `navbar-nav` to an
`<ul>` tag in a list-based navbar. In fact, `navbar-nav` seems to
override all the css properties set by `nav`.
Also, `nav-item` class should be used only for `<li>` tags, or in
conjunction with `<a>` tags to entirely avoid the list-based approach.
This commit removes the redundant `nav` class from `navbar-nav` `<ul>`
tags, moves `nav-item` from `<a>` tags to `<li>` tags and properly
adds `nav-item` class to `<li>` tags where missing.
Refs:
* https://v4-alpha.getbootstrap.com/components/navs/
* https://v4-alpha.getbootstrap.com/components/navbar/#nav
* add the svg icon as a partial so we can include it easily
* add the icon to the homepage
* drop .bd-booticon for svgs here
* rip out the import for .bd-booticon sass file
* Delete _booticon.scss
* indentation
* Update bootstrap-icon.html
* remove those
* Fixed dead link to browser list
The link to the list of browsers supported through Autoprefixer was dead, now updated to a working link.
* Updated label to display new file path
Changed the labeling on the updated link to show read as the new updated file path.
The link to package.json in the v4 docs was linking to package.json in the v3 source. Fixed to point to the correct v4 location. A change like this will need to be made for all branches on version 4 if you want the docs to be linked correctly (github may be smart enough to follow the link to the current branch if you are on github but it was wrong from the main site).
* Fix incorrect code indentation
* Remove unnecessary vendor prefix for `box-sizing` - all modern browsers now support this unprefixed
* Remove incorrect `<label>` and change static controls to readonly inputs
* Allow `<img>` elements without `src` to allow for `holder.js` images used in the docs, which lack `src` and use `data-src` instead
As the question often comes up about why Bootstrap does not do "true"
ARIA menus (with their `role="menu"` etc), add an admittedly lengthy
note (tl;dr because BS is generic, and ARIA menus are specific and quite
limiting).
Additionally, fixes up the `<a>` example for dropdown trigger, with the
missing `role="button"` and neutering the `href` (which would be useless
anyway since BS overrides the link-like nature of the `<a>` so it could
never be triggered/followed anyway)
* Add carousel mouse listeners even if touch events enabled
- touch events are enabled not just on "mobile", just also on
touch-enabled desktop/laptop devices; additionally, it's possible to
pair a mouse with traditionally touch-only devices (e.g. Android
phones/tablets); currently, in these situations the carousel WON'T pause
even when using a mouse
* Restart cycle after touchend
as `mouseenter` is fired as part of the touch compatibility events, the
previous change results in carousels which cycle until the user
tapped/interacted with them. after that they stop cycling (as
`mouseleave` is not sent to the carousel after user scrolled/tapped
away).
this fix resets the cycling after `touchend` - essentially returning
to the previous behavior, where on touch the carousel essentially never
pauses, but now with the previous fix it at least pauses correctly for
mouse users on touch-enabled devices.
includes documentation for this new behavior.
A long overdue rewrite of the accessibility section - instead of the few
snippets of strangely superficial and out-of-context advice (skip links,
use correct heading levels), this tries to answer some of the
fundamental questions about "is Bootstrap accessible", with emphasis on
the fact that the final result will depend in large part on what BS is
applied to/on (since BS relies on the markup etc authored by
developers). This also sets out our ambition to have things work for
keyboard and assistive tech users, and that we strive to make all our
examples etc accessible and semantic.
* Changes based on @mdo's feedback
This makes them keyboard-accessible. For mouse users, the only change
here is that the focus outline will remain on the button once clicked
(in future, this can be solved with :focus-ring, but for now this would
require a polyfill). the tooltip is explicitly hidden on `mouseleave`,
so even though the `<button>` retains focus after clicking, the tooltip
won't stay visible once mouse user moves away.
the mouse hover styles have explicitly not been make to also apply to
:focus, so as to minimise the visual impact for
mouse users (though the tooltip remains visible)
- but due to the default outline and the custom tooltip, it
should be fairly clear when keyboard users set focus to a copy button
too.
* Replace backdrop with simple noop mouse listener
As discussed in https://github.com/twbs/bootstrap/pull/22422 the current
approach of injecting a backdrop (to work around iOS' broken event
delegation for the `click` event) has annoying consequences on
touch-enabled laptop/desktop devices.
Instead of a backdrop `<div>`, here we simply add extra empty/noop
mouse listeners to the immediate children of `<body>` (and remove
them when the dropdown is closed) in order to force iOS to properly
bubble a `click` resulting from a tap (essentially, method 2 from
https://www.quirksmode.org/blog/archives/2014/02/mouse_event_bub.html)
This is sufficient (except in rare cases where the user does manage to tap
on the body itself, rather than any child elements of body - which is not
very likely in an iOS phone/tablet scenario for most layouts) to get iOS to
get a grip and do the correct event bubbling/delegation, meaning the regular
"click" event will bubble back to the `<body>` when tapping outside of the dropdown,
and the dropdown will close properly (just like it already does, even without
this fix, in non-iOS touchscreen devices/browsers, like Chrome/Android and
Windows on a touch laptop).
This approach, though a bit hacky, has no impact on the DOM structure, and
has no unforeseen side effects on touch-enabled laptops/desktops. And crucially,
it works just fine in iOS.
* Remove dropdown backdrop styles
* Update doc for dropdowns and touch-enabled devices
...as touch is not exclusive to "mobile" anymore nowadays. also explicitly clarifies this is a fix for iOS, and that it impacts touch laptops etc as well. lastly, renames the variable from "dropdown" to "backdrop" for clarity/consistency
* Remove aria-expanded from collapse.js target element
aria-expanded="true"/aria-expanded="false" only applies to the trigger,
not the element that is being expanded/collapsed.
* Tweak collapse.js accessibility section
...to make it clearer that the aria-expanded attribute always just goes
on the control.
* Fix collapse.js unit tests
- reword some of the text to make it clear we're checking behavior of
trigger/control
- move incorrect aria-expanded out of the <div>s and to the actual
trigger/control <a>s
- fix incorrect test assertion text output false -> true
While `placeholder` is nominally valid per spec
http://rawgit.com/w3c/html-api-map/master/index.html#accessible-name-and-description-calculation
it is inelegant, a fallback, and not supported in ios/safari/voiceover
and android/chrome/talkback, to name a few combinations
`aria-describedby` is also not really the right tool for providing a
name/label equivalent, so remove that from the list of possible
alternative methods / clarify how it can be used
- add .col-*-auto to the extend in our grid framework mixins so it gets padding
- this means we can avoid the col-12 classes in our docs for the responsive variants
The example code has the class `"modal fade"`, but the visible example has the class `"modal"`. `"fade"` appears to not work for modals that you do not intend to animate onto the page
