Date pickers, comboboxes, menus and popovers all open a panel on top of the page. The moment that panel opens, the keyboard has a question to answer: where does the focus go now, where may it go next, and where does it land when the panel closes? Get it wrong and a keyboard user walks out of an open calendar into the page behind it, or a screen reader user is sent back to the top of the document after picking a date.

This guide covers how to answer those questions in a way that works for keyboard users, screen reader users and everyone using a mouse or a finger. The examples are plain JavaScript, so they apply to any framework.

Bootstrap published its first v6 alpha on October 8. CoreUI v6 followed with its first alpha two weeks later. CoreUI has been built on Bootstrap from the start, so the obvious question is how close the two v6 lines are.

The short answer: as close as we could make them, with a list of deliberate exceptions. For every file we share with Bootstrap we follow one rule. Class names, CSS custom properties, options, events and public methods stay the same as in Bootstrap wherever we can manage it, so moving from one to the other does not mean rewriting markup. The code behind those names is a separate question. Where we can do better than Bootstrap without changing a name, we do. Where following Bootstrap would cost our users a migration step that buys them nothing, we don’t.

This post goes through all three cases: what we took, what we left out, and where we kept the name but changed what is behind it.

Open almost any date picker, press Tab until you reach the grid, and focus lands on a day. Which day it can land on, and which days the arrow keys can reach, comes down to one small decision that most implementations make without noticing: can an unavailable date receive focus?

The intuitive answer is no. A disabled date is disabled, so you render it as <button disabled>, the browser skips it, and you move on. It looks right in a demo. It stops being right as soon as a real product starts disabling dates: weekends, public holidays, fully booked days, a minimum notice period, a cut-off time.

This post describes the model we use in the CoreUI v6 Calendar, and why: a cell’s focusability depends only on the calendar’s limits. Everything else decides only whether the cell can be selected.

“Add a calendar” is one of those requirements that means five different things depending on who says it. A form field for picking a delivery date is a calendar. A month grid showing this sprint’s deadlines is a calendar. A week view where a dispatcher drags jobs between technicians’ columns is also, apparently, a calendar.

These are not sizes of the same feature — they are different features with different costs, and Bootstrap itself ships none of them. Bootstrap 5 has no calendar component at all: no date picker, no month grid, no scheduler. So every “bootstrap calendar” is Bootstrap’s design language plus a component that comes from somewhere else — a library, or your own code.

This article climbs that ladder honestly: what each rung actually requires, what you can reasonably build yourself, and where the cost curve bends hard enough that building stops making sense.

Every Bootstrap data table starts the same way: a <table class="table">, a loop over some rows, done. And for a surprising number of applications, that is genuinely all you need.

Then the requirements arrive one at a time. “Can we sort this by date?” “Can I search it?” “It’s slow with this quarter’s data.” Each one looks small, and each one is answerable with a few lines of JavaScript — until, at a fairly predictable point, it isn’t.

This article walks that ladder honestly. For each threshold we show what you can build yourself with plain Bootstrap (or CoreUI, which shares the same table markup and classes) and vanilla JavaScript, where the hand-rolled version starts to leak, and at which rung it stops being reasonable to keep writing table infrastructure by hand. If your table has 50 rows and never will have more, the code below is all you need — no library, no license, nothing to ship but a few kilobytes of your own JavaScript.

Raising numbers to powers is essential for mathematical calculations, exponential growth models, compound interest, and geometric progressions in JavaScript applications. As the creator of CoreUI, I’ve used exponentiation in calculators, financial tools, and chart scaling utilities. For square roots (power of 0.5), see how to get the square root of a number in JavaScript.

Calculating square roots is important for geometric calculations, distance formulas, statistical analysis, and data visualization in JavaScript applications. As the creator of CoreUI, I’ve used square root calculations in geometric utilities, chart scaling, and physics-based animations. For rounding results before display, see how to round a number in JavaScript.

Getting the absolute value of a number is essential for distance calculations, difference measurements, range validation, and progress indicators in JavaScript applications. As the creator of CoreUI, I’ve used Math.abs() in progress bars, difference meters, and validation systems where magnitude matters more than sign. For rounding considerations after computing absolute values, see how to round a number in JavaScript.

Converting radians to degrees is essential for displaying trigonometric results, rotation controls, compass displays, and geometric utilities in JavaScript applications. As the creator of CoreUI, I’ve used this conversion in rotation sliders, angle indicators, and chart label formatting. JavaScript’s Math.atan2(), Math.asin(), and Math.acos() return radians — convert to degrees before displaying to users. For the inverse operation, see how to convert degrees to radians in JavaScript.

Converting degrees to radians is essential for trigonometric functions, canvas graphics, SVG animations, and geometric transformations in JavaScript applications. As the creator of CoreUI, I’ve used this conversion in chart rotations, animation systems, and canvas-based components. JavaScript’s Math.sin(), Math.cos(), and Math.tan() all expect radian values — degrees must be converted before use. For the inverse operation, see how to convert radians to degrees in JavaScript.