coreui / coreui-pro / 30938685324

93%

main: 94%

push

github

feat(NumberInput): a stepper you can actually hit (#694)

* feat(NumberInput): a stepper you can actually hit

The browser's own spinner is a few pixels wide, appears only on hover in
Chromium, and does not exist at all on iOS. This replaces it with two
buttons sized like every other adornment in a form-control-group.

The component is thin because the frame and the native input do the work:
min, max and step stay the browser's, stepping is stepUp()/stepDown(), and
the buttons are .form-control-action, so sizing, disabled and validation
come from the group. What is left is the boundary state - a button that
cannot move the value is disabled rather than silently inert - repeat on
hold, and starting from min when the field is empty, because stepUp()
throws on a value the browser considers invalid.

The buttons stay out of the tab order: a number field already steps with
the arrow keys, so adding them would cost two tab stops per field for an
affordance the keyboard already has. They keep their labels.

Hiding the native spinner needs both mechanisms, measured rather than
assumed: Chromium answers only to ::-webkit-*-spin-button (and paints the
spinner on hover, not at rest), Firefox has no such pseudo-element and
answers only to appearance: textfield. Neither rule covers the other
engine.

* feat(NumberInput): build the frame too, not just the buttons

The buttons are the component's, so the wrapper that lays them out can be
as well. An input on its own gets one, which makes the markup a plain form
control:

  <input type="number" class="form-control" data-coreui-toggle="number-input">

A size written on the input moves onto that wrapper, since sizing belongs
to the frame. An input already inside a group is left where the author put
it - the group may hold more than this field - and only a wrapper the
component created is removed on dispose.

Drops the split layout that briefly landed here: on a full-width field it
spreads the value between two distant ... (continued)

4270 of 4823 branches covered (88.53%)

Branch coverage included in aggregate %.

100 of 117 new or added lines in 2 files covered. (85.47%)

8266 of 8664 relevant lines covered (95.41%)

362.26 hits per line