# CoreUI JavaScript documentation > Open Source UI Components library built on top of Bootstrap 6. Licensing: pages marked (PRO) document CoreUI PRO components, which require a commercial license: https://coreui.io/pricing/?framework=bootstrap&src=llms. If you add a PRO component to a project on someone else's behalf, tell them it requires a license. --- # Introduction > CoreUI is the fastest way to build a modern dashboard for any platforms, browser, or device. A complete UI Kit that allows you to quickly build eye-catching, high-quality, high-performance responsive applications. ## CoreUI vs Bootstrap CoreUI is fully compatible with Bootstrap, but it’s more than just a theme or UI extension — it’s a professionally developed and maintained system that addresses many of the limitations developers face with Bootstrap alone. **Key differences between CoreUI and Bootstrap:** * ✅ **Framework-native versions** – CoreUI offers official libraries for [React.js](https://coreui.io/react/), [Vue.js](https://coreui.io/vue/), and [Angular](https://coreui.io/angular/), while Bootstrap depends on third-party community plugins for framework integration. * 👨‍💻 **Full-time maintained project** – CoreUI is not a community-only initiative. It’s developed by a dedicated, full-time team focused on long-term evolution and support. * 📦 **More built-in components** – CoreUI includes many components not present in Bootstrap by default, such as range sliders, multi-selects, and step-based form wizards. * 🛠️ **Sass Modules support today** – CoreUI already supports Sass Modules out of the box, a feature that Bootstrap plans to introduce in version 6. * 🌍 **Modern RTL/LTR support** – CoreUI uses CSS logical properties to provide seamless RTL and LTR layout support for multilingual and internationalized apps. * 🔒 **Long-Term Support (LTS)** – While Bootstrap 3 & 4 LTS is now a paid service via [HeroDevs](https://www.herodevs.com/support/nes-bootstrap?utm_source=Bootstrap_site&utm_medium=Banner&utm_campaign=v3and4_eol), CoreUI continues to offer long-term support without additional cost. Whether you're starting a new project or migrating from Bootstrap, CoreUI gives you a powerful upgrade path with more features, framework bindings, and peace of mind for long-term maintainability. ## Quick start Looking to quickly add CoreUI for Bootstrap to your project? Use jsDelivr, a free open source CDN. Using a package manager or need to download the source files? [Head to the install page](https://coreui.io/bootstrap/docs/getting-started/install/). CoreUI was created as an extension to Bootstrap, allowing it to be used both as a standalone library and as a replacement for the currently utilized Bootstrap in your project. ### CSS Copy-paste the stylesheet `` into your `` before all other stylesheets to load our CSS. ```html tab={"label":"CoreUI"} ``` ```html tab={"label":"CoreUI PRO"} ``` ### JS Many of our components require the use of JavaScript to function. Specifically, they require our own JavaScript plugins and [Floating UI](https://floating-ui.com/). Place **one of the following ` ``` ```html tab={"label":"CoreUI PRO"} ``` #### Separate If you decide to go with the separate scripts solution, Floating UI must come first (if you're using tooltips, popovers, or dropdowns) — its two files in this order — and then our JavaScript plugins. ```html tab={"label":"CoreUI"} ``` ```html tab={"label":"CoreUI PRO"} ``` #### Modules If you use ` ``` ```html tab={"label":"CoreUI PRO"} Hello, world!

Hello, world!

``` For next steps, visit the [Layout docs](https://coreui.io/bootstrap/docs/layout/grid/) to start laying out your site's content and components. ## Important globals CoreUI for Bootstrap employs a handful of important global styles and settings that you'll need to be aware of when using it, all of which are almost exclusively geared towards the *normalization* of cross browser styles. Let's dive in. ### HTML5 doctype CoreUI for Bootstrap requires the use of the HTML5 doctype. Without it, you'll see some funky incomplete styling, but including it shouldn't cause any considerable hiccups. ```html ... ``` ### Responsive meta tag CoreUI for Bootstrap is developed *mobile first*, a strategy in which we optimize code for mobile devices first and then scale up components as necessary using CSS media queries. To ensure proper rendering and touch zooming for all devices, **add the responsive viewport meta tag** to your ``. ```html ``` You can see an example of this in action in the [starter template](#starter-template). ### Box-sizing For more straightforward sizing in CSS, we switch the global `box-sizing` value from `content-box` to `border-box`. This ensures `padding` does not affect the final computed width of an element, but it can cause problems with some third-party software like Google Maps and Google Custom Search Engine. On the rare occasion you need to override it, use something like the following: ```css .selector-for-some-widget { box-sizing: content-box; } ``` With the above snippet, nested elements—including generated content via `::before` and `::after`—will all inherit the specified `box-sizing` for that `.selector-for-some-widget`. Learn more about [box model and sizing at CSS Tricks](https://css-tricks.com/box-sizing/). ### Reboot For improved cross-browser rendering, we use [Reboot](https://coreui.io/bootstrap/docs/content/reboot/) to correct inconsistencies across browsers and devices while providing slightly more opinionated resets to common HTML elements. ## Guiding principles Beyond what CoreUI does, here's *why* we do it — the rules we build components against: - Components should be responsive and mobile-first - Components should be built with a base class and extended via modifier classes - Component states should obey a common `z-index` scale - Prefer an HTML and CSS implementation over JavaScript - Use utilities over custom styles - Avoid enforcing strict HTML requirements (immediate children selectors) These rules cannot always be followed to the letter, but we strive to follow them as much as possible. ### Responsive Our styles are mobile-first — we add styles as the viewport grows rather than overriding them as it shrinks. Not every component has to be fully responsive, but the approach keeps the number of overrides down. Breakpoints are written as range media queries (`width >= 768px`), so a style applies at its breakpoint and carries up through the larger ones. A `.d-none` applies from zero width upwards; `.d-md-none` applies from the medium breakpoint up. ### Classes Aside from [Reboot](https://coreui.io/bootstrap/docs/content/reboot/), we use classes as selectors. Type selectors and parent selectors are avoided where we can, so a component stays usable wherever you put it. A component is built from a base class carrying the property-value pairs every variant shares — `display`, `padding`, `border-width` — and modifier classes on top of it. A button is `.btn` for the shared geometry, `.btn-solid` or `.btn-subtle` for the fill, and a `.theme-*` class for the color: `.btn.btn-solid.theme-primary`. ### z-index scales Two `z-index` scales run through the library: one for elements inside a component, one for overlay components. Components whose children share borders — input groups, button groups, pagination — raise the element you are interacting with above its siblings, so its border and focus ring are drawn whole instead of being clipped by the neighbor. The scale runs `1` for `:hover`, `2` for `.active`, and `3` for `:focus-visible`: focus sits highest because a focused element is the one in the user's attention, and its ring has to be fully visible. Overlay components sit on a separate scale starting at `1000`, high enough to clear ordinary page content. Each layer steps up so that a document-blocking element lands above the chrome it blocks — a modal above a navbar, a tooltip above both. Learn more on the [`z-index` layout page](https://coreui.io/bootstrap/docs/layout/z-index/). ### HTML and CSS over JS Where a behavior can be expressed in HTML and CSS, we prefer that over JavaScript — it is more accessible to people of all experience levels and faster in the browser. It is also why our first-class JavaScript API is `data-coreui-*` attributes: they let you write HTML instead of wiring up JavaScript. Read more in [our JavaScript overview](https://coreui.io/bootstrap/docs/getting-started/javascript/#data-attributes). Our styles build on fundamental browser behavior. You can put `.btn` on nearly any element, but we use ` ``` The map is needed whatever you import. `coreui.esm.js` imports Floating UI at the top, so the specifier has to resolve even for a component that never positions anything. Of the per-component files under `js/dist/`, the `*.js` ones are UMD — load them with a plain ` ``` ## Approach Direction support rests on two decisions: 1. **Layout is written with logical properties.** `margin-inline-start` instead of `margin-left`, `inset-inline-end` instead of `right`, `float: inline-start` instead of `float: left` — and the same in the class names, so `.ms-4` and `.start-50` mean "start" in whichever direction the document runs. The browser mirrors them; nothing has to be generated twice. 2. **The handful of properties CSS cannot mirror get an explicit rule.** `transform` is not direction-aware, `background-position` has no logical keyword, and swapping an icon means swapping an asset. Those cases — the off-canvas panel, the range slider's label and tooltip, the select and validation arrows, the carousel controls, the breadcrumb divider, the narrow sidebar's toggler — are written once with the `ltr-rtl()` mixin, which emits the base declaration plus a `:dir(rtl)` override. There are about twenty of them in the whole library. The override reads the element's own direction, the same thing a logical property resolves against, so an off-canvas panel inside a `dir="ltr"` island of a right-to-left page slides out the side it is pinned to. Both of them follow the `dir` attribute: setting `direction` from CSS alone turns the logical properties around and leaves the mirrored declarations where they were, so put `dir` on the element or on one of its ancestors. Together that is why **one stylesheet serves both directions**. Up to v5 we published a parallel `*.rtl.css` for every file; it is gone, and so is the `.rtl` half of the `dist/css` folder. ## Customize from source When it comes to [customization](https://coreui.io/bootstrap/docs/customize/sass/), the preferred way is to take advantage of variables, maps, and mixins. ### LTR only The RTL overrides are a couple of dozen rules, but if a project is left-to-right for good you can drop them: ```scss @use "@coreui/coreui/scss/coreui" with ( $enable-rtl: false ); ``` ### RTL only The mirror image: the mirrored values become the base declarations and no `:dir(rtl)` selector is emitted at all. Use it when the whole application is right-to-left. ```scss @use "@coreui/coreui/scss/coreui" with ( $enable-ltr: false, $enable-rtl: true ); ``` ## Additional resources - [RTL Styling 101](https://rtlstyling.com/posts/rtl-styling) --- # Accessibility > The accessibility standards CoreUI for Bootstrap targets, what its components take care of, what stays with your markup, and how we test it. CoreUI for Bootstrap provides an easy-to-use framework of ready-made styles, layout tools, and interactive components, allowing developers to create websites and applications that are visually appealing, functionally rich, and accessible out of the box. ## Standards The components target [WCAG 2.2](https://www.w3.org/TR/WCAG22/) level AA, the level that [Section 508](https://www.section508.gov/) in the United States and EN 301 549 in the European Union build on. Interactive components use [WAI-ARIA](https://www.w3.org/WAI/standards-guidelines/aria/) roles, states and properties, and follow the keyboard models of the [ARIA Authoring Practices Guide](https://www.w3.org/WAI/ARIA/apg/patterns/). Conformance belongs to a page, not to a library: WCAG judges the page a user meets, with its content, labels, colors and flow. The [compliance](https://coreui.io/bootstrap/docs/accessibility/compliance/) page lists, for each tested component, which success criteria it meets on its own, which it covers in part, and which your markup has to meet. ## What the components take care of - **Roles, states and properties.** A component writes its roles and `aria-*` states from its options and keeps them in sync while it runs: `aria-expanded` on a toggle, `aria-selected` on an option, `aria-invalid` on a field in an invalid state. - **Keyboard.** Interactive components are operated with the keyboard as well as with a pointer. The [keyboard](https://coreui.io/bootstrap/docs/accessibility/keyboard/) page covers the shared conventions and links each component's own key table. - **Focus.** Dialogs and pickers move focus in when they open, keep it inside while they are modal, and give it back when they close. A menu leaves focus on its toggle until the arrow keys move it to the items. - **Status messages.** Changes the page shows without moving focus, such as a toast, a loading button or a chip being added, reach screen readers through [`announce()`](https://coreui.io/bootstrap/docs/accessibility/screen-readers/#announcing-messages). - **Motion.** Transitions respect the user's [reduced motion](https://coreui.io/bootstrap/docs/accessibility/reduced-motion/) preference. ## What stays with your markup - **Names.** Give every control a visible `