coreui / coreui-pro / 31269425939

93%

main: 94%

Build Type

push

github

Committed by web-flow

Commit Message

fix(range-slider): stop painting the slider from JavaScript (#724)

* fix(range-slider): position the tooltip in CSS and make it an <output>

The tooltip was placed by JavaScript on every value change: an inline
`inset-inline-start` percentage plus a margin compensating for the handle's
width, read from the stylesheet with `getComputedStyle` and parsed by a regex.

The compensation is algebra that CSS can do. `percent·W + (0.5 − percent)·T`
reduces to `T/2 + percent·(W − T)` — the handle's centre — so the stylesheet
computes it from one ratio the plugin keeps in sync, and the vertical
orientation becomes a second declaration instead of a second code path.

That deletes `_getThumbSize()` along with two defects it carried: its fallback
returned a string where callers expected `{value, unit}`, so a handle width the
regex could not read (`calc()`, `var()`) produced `NaNundefined` and dropped the
compensation entirely; and the ternary in `_positionTooltip()` computed the same
expression in both branches.

The tooltip is an `<output>` now — the element for a value derived from a
control — with `<span>` children, because `<output>` takes phrasing content and
Bootstrap's own `<div>`s inside one are invalid. Ours needs no extra CSS for
that: the tooltip is a flex container, so the spans are blockified anyway.
`aria-hidden="true"` is not optional here: measured through CDP, an `<output>`
without it enters the accessibility tree as `role="status"` with `live="polite"`,
which would announce the value a second time on every drag on top of the
handle's own `aria-valuenow`.

Verified in Chromium that nothing moves: the tooltip's position is identical
across 60 combinations — LTR and RTL, horizontal and vertical, three handle
sizes, five values — and the `<output>`/`<span>` markup renders pixel-identical
to the old `<div>`s across 19 measured properties.

* fix(range-slider): build the track's fill in CSS, and fix it under a changed prefix

The gradient was assembled... (continued)

Coverage Stats

4255 of 4805 branches covered (88.55%)

Branch coverage included in aggregate %.

10 of 10 new or added lines in 1 file covered. (100.0%)

1 existing line in 1 file now uncovered.

8265 of 8660 relevant lines covered (95.44%)

364.26 hits per line