coreui / coreui-pro / 35772254145

95%

main: 94%

push

github

fix(Calendar): make each date grid one tab stop (#1390)

The table declares role="grid" and every selectable cell carried tabindex="0",
so Tab walked 30 day cells before reaching anything after the calendar, 12 in
the months view, and every row in week mode. APG's grid is a composite with one
tab stop: arrows move inside it, Tab moves out. Arrows, Home, End and the page
keys already worked here; only the tab stops were wrong.

tabindex="0" was doing double duty as the "this cell can be selected" marker --
the arrow navigation and twelve event bindings resolve their targets through
.calendar-cell[tabindex="0"] -- so selectability moves to its own
data-coreui-selectable attribute and tabindex is left to a roving pass. Each
panel keeps a stop of its own, because each panel is a grid of its own: a
two-month range picker is two composites, not one. The stop goes to the
selected date, else the selectable cell closest to the calendar date, and
follows focus from there.

The closest-by-date search measures whole periods, not milliseconds. Cell dates
sit at the start of what they stand for, so a calendar date of 2026-09-22 was
9 days from October and 21 from September: the months view parked its stop on
October, the quarters view on Q4 and the years view on 2027. It now normalizes
the requested date to the view's own unit, and to midnight in the days view,
where a clock time used to pick tomorrow for any afternoon.

Weeks are picked by the row only while the grid shows days. The month and year
views of a week picker are cell grids like any other, and _getDate threw
resolving a cell as a row there, which left those views with no tab stop at all.

The panel entry resolves the same way for every picker: the selected value,
else today, else the stop the grid parked. Its old "last stop" fallback only
made sense while every cell was a stop. util/calendar's getSelectableDates
defaults to the new marker, as the React and Vue copies already do.

Measured in Chromium: t... (continued)

5898 of 6504 branches covered (90.68%)

Branch coverage included in aggregate %.

41 of 41 new or added lines in 3 files covered. (100.0%)

11110 of 11496 relevant lines covered (96.64%)

587.53 hits per line