feat(slider): single and dual range slider on native inputs

[mplatts]

Closes #608

Summary

A first-class <.slider>: single and dual thumb, marks, a tooltip or inline value readout, sizes, vertical orientation and disabled. It absorbs the display work that lived in field.ex/input.ex and adds what those types could not carry.

Five parts per CONTRIBUTING.md:

• lib/petal_components/slider.ex (exported from lib/petal_components.ex)
• a pc-slider section in assets/default.css, appended as its own @layer components block, nothing reflowed
• test/petal/slider_test.exs (32 tests) and test/js/slider.test.js (18 tests)
• lib/petal_components/showcase/slider.ex + its registry.ex entry
• the slider playground page in dev.exs, rebuilt around <.slider>

Plus ### Unreleased in CHANGELOG.md and deprecation notes on the range / range-dual docs.

Native <input type="range">, not role="slider"

I went native, as the issue proposed, and the keyboard argument decided it on its own. The WAI-ARIA slider pattern's whole keyboard map — arrows, Home, End, PageUp, PageDown — plus role="slider", aria-valuemin/valuemax/valuenow, touch and pointer handling, and form posting, all arrive for free and stay correct across browsers and assistive tech. A custom role="slider" implementation would mean re-implementing every one of those and getting them all right, in exchange for styling freedom I did not actually need: the track, fill, thumb, marks and tooltip are drawn as real sibling elements under the input, with the input's own track and thumb painted out. That sidesteps the usual native-styling ceiling, and it fixes a real bug class along the way — dark: and --pc-radius resolve on real elements but cannot on ::-webkit-slider-runnable-track (a dark: variant compiles to a trailing :where(.dark, …) ancestor test a pseudo-element can never satisfy, which is why .pc-range-input's track used to stay light in dark mode).

On dual and native: correct, one native input cannot carry two thumbs. Dual mode is two overlaid native inputs, each posting its own name — the technique the existing pc-dual-range already uses. That keeps both thumbs individually focusable and keyboard-operable, which a single custom two-thumb widget makes materially harder. It did not push me toward a custom implementation; it is the one place a hook is genuinely required (see below).

I verified the keyboard map by hand in the playground rather than assuming it: on the volume slider, 60 → 62 (two ArrowRights), → 72 (PageUp), → 0 (Home), → 100 (End).

CSS-first, and the one thing the hook is for

Geometry rides --pc-slider-pct (and -min/-max) custom properties that the server renders inline, so the control paints correctly before any JS connects and with JS off entirely. The fill, both tooltips and every tick anchor off those same properties, so positioning is pure CSS with nothing measured.

PetalSlider does only what the client alone can know:

1. keeping the percentages live while you drag
2. the ordering invariant two overlaid inputs cannot enforce themselves, including the z-index lift when the thumbs meet (without it, one thumb becomes unreachable once they overlap)
3. emitting a bubbling petal:slider-change CustomEvent for apps that want the value without a form

JS.dispatch and CSS cannot do (1) or (2) — there is no declarative hook for "the user is dragging a native range thumb". Everything else is CSS.

Deviations from the issue's API sketch

Three additions, no removals. Everything in the sketch is present with the sketched names and defaults.

1. label added. The sketch has no attr that can name the inputs, but an input must never be nameless. label is the accessible-name base and a visible label above the track; it defaults to the humanised field name. Dual thumbs become "<label> minimum" / "<label> maximum", which is the naming the issue's a11y section asks for.
2. min_name / max_name added. The test checklist asks for dual names "from values + explicit names", but a single name cannot express two. values + name derives "<name>_min" / "<name>_max"; these two override it.
3. rest applies to the wrapper, not the inputs. The issue suggests overriding the dual thumbs' aria-label via rest, but rest is one bag of attributes and dual mode needs two different labels, so it cannot express that. label is the override instead. Wrapper is also where phx-hook and the geometry properties live, so it is the natural target.

Also: errors from the form field(s) render through PetalComponents.Field.field_error (merged and de-duplicated across both thumbs, matching how field.ex merges min/max errors), so <.slider> is usable directly in a form without wrapping it in <.field>.

Not done from the issue: the vertical orientation is verified in Chrome only (screenshot below). The issue asks for a VoiceOver pass, which I could not run; writing-mode: vertical-lr + direction: rtl is the standards-track approach with appearance: slider-vertical as the legacy WebKit fallback, and the input is unchanged otherwise, so the announcement should be identical — but that is reasoning, not a test. Firefox was likewise not exercised; the CSS carries both the ::-webkit-* and ::-moz-* branches, following the existing split.

The pre-existing slider situation

Worth reporting, since it was ambiguous going in:

• There was no Slider module and no slider commit history. git log --all -- '*slider*' is empty, and lib/petal_components.ex had slider free, as the issue said.
• The playground nav entry was not stale. main already had a full, working slider page — but it demoed <.field type="range"> and type="range-dual", pulling its examples from the Field showcase (~w(sliders slider_dual)a). So the slug was real and occupied, not a placeholder.
• Given the strict one-slug-per-component rule, I replaced that page rather than adding a second one. The new page keeps the slider slug and is built entirely on <.slider>, with the six dials the issue specifies (mode, marks, show_value, orientation, step, size — plus disabled) and the three scenarios (price-range filter, volume, year picker), a keyboard hint line, and a closing note pointing at the deprecated field types. Verified it renders and does not fall back to the Button page.
• origin/dual-range-slider is stale and superseded. Its 10 commits are not reachable from main, but the feature they built is on main (squash-merged), so the branch is history, not pending work. I did not build on it; the issue's brief supersedes it.
• The Field showcase keeps its sliders / slider_dual examples so the deprecated types stay documented on petal.build; both descriptions now say they are superseded by <.slider>.

Verification

Gate	Result
mix format --check-formatted	clean
mix compile --force --warnings-as-errors	clean
mix credo	zero new entries (44 issues before and after, diffed line-for-line vs origin/main)
mix test	913 → 945, 0 failures, 1 skipped (+32)
npm test	157 → 175 (+18)

No test was weakened or deleted. No new dependencies — no npm package, no hex dep.

Exercised in the playground on :4023: every dial, light and dark, dual, marks, vertical, tooltip-on-hover, and keyboard-only.

Screenshots

Light and dark of the playground page, thumbs at non-default positions so the fill/track relationship is visible.

Also captured while verifying (happy to attach if useful): dual + vertical, marks with the tick inversion inside the fill, and the tooltip bubble anchored to the thumb.

---

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.75%. Comparing base (871b2cf) to head (9aa25b4).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #636      +/-   ##
==========================================
+ Coverage   92.40%   92.75%   +0.35%     
==========================================
  Files         119      121       +2     
  Lines        5066     5231     +165     
==========================================
+ Hits         4681     4852     +171     
+ Misses        385      379       -6     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mplatts]

Screenshots

Light / dark, thumbs at non-default positions

Dials — dual + marks + tooltip, vertical, marks + tooltip

Keyboard — End key driving the value to 100

Verified independently

Check	Result
mix test	945 tests, 0 failures, 1 skipped (+32)
npm test	175 passing (+18)
mix format / compile -Werror	clean
mix credo	zero new entries vs main (the field.ex complexity finding just shifts line 249 → 257)
new dependencies	none
slugs : clauses	60 : 60

The slug situation is worth reading

The slider nav entry on main was not a placeholder — it was a full working page demoing <.field type="range"> / "range-dual", pulling from the Field showcase. Given the strict one-slug-per-component rule, this PR replaces that page rather than adding a second, which is why the count stays at 60 rather than going to 61. Separately, origin/dual-range-slider turned out to be history not pending work: its commits aren't reachable from main, but the feature they built is (squash-merged).

The field.ex / input.ex changes are documentation only — I checked specifically. No runtime warning, no raise, no behaviour change; type="range" keeps working. Just an info callout pointing new code at <.slider>. Whether to actually deprecate is your call, not something this PR forces.

Going native <input type="range"> with the track/fill/thumb drawn as real sibling elements also dodges a live bug class: dark: can't resolve on ::-webkit-slider-runnable-track, which is why .pc-range-input's track used to stay light in dark mode.

Keyboard verified by hand: 60 → 62 (ArrowRight ×2) → 72 (PageUp) → 0 (Home) → 100 (End).

Not verified: Firefox (CSS carries both ::-webkit-* and ::-moz-* branches), a VoiceOver pass on vertical orientation, and prefers-reduced-motion with the media feature actually forced on.

_{Images live on the pr-assets branch, which exists only to host PR screenshots - it never merges to main and ships in no Hex release.}