Bootstrap: feat(custom-range): Add support for input-group and validation

[tmorehouse]

Currently the .custom-range input does not support validation styling, nor is .custom-range supported inside .input-groups.

I suggest CSS similar to the following to handle both input-groups and validation

Basic validation:

.custom-range {
  border: 1px solid transparent;
  border-radius: .25rem;
}
/* leave above out to not have the non .input-group ranges
 * bordered when invalid or valid
 */

.custom-range.is-invalid,
.was-validated .custom-range:invalid {
  border-color: #dc3545;
}
.custom-range.is-invalid:focus,
.was-validated .custom-range:invalid:focus {
  border-color: #dc3545;
  box-shadow: 0 0 0 .2rem rgba(220,53,69,.25);
}
.custom-range.is-valid,
.was-validated .custom-range:valid {
  border-color: #28a745;
}
.custom-range.is-valid:focus,
.was-validated .custom-range:valid:focus {
  border-color: #28a745;
  box-shadow: 0 0 0 .2rem rgba(40,167,69,.25);
}

Input groups:

.input-group > .custom-range {
  display: block;
  height: calc(2.25rem + 2px);
  padding: 0 .75rem;
  font-size: 1rem;
  line-height: 1.5;
  background-clip: padding-box;
  border: 1px solid #ced4da;
  border-radius: .25rem;
  transition: border-color .15s ease-in-out, box-shadow .15s ease-in-out;
}
.input-group > .custom-range {
  position: relative;
  -ms-flex: 1 1 auto;
  flex: 1 1 auto;
  width: 1%;
  margin-bottom: 0;
}
.input-group > .custom-range:focus {
  z-index: 3;
}
.input-group-sm > .custom-range {
  height: calc(1.8125rem + 2px);
  padding: 0 .5rem;
  font-size: .875rem;
  line-height: 1.5;
  border-radius: .2rem;
}
.input-group-lg > .custom-range {
  height: calc(2.875rem + 2px);
  padding-left: 0 1rem;
  font-size: 1.25rem;
  line-height: 1.5;
  border-radius: .3rem;
}
.input-group > .custom-range:not(:last-child) {
  border-top-right-radius: 0;
  border-bottom-right-radius: 0;
}
.input-group > .custom-range:not(:first-child) {
  border-top-left-radius: 0;
  border-bottom-left-radius: 0;
}

/* Style for focusing custom-range when inside an .input-group.
 * Normally only the range thumb has focus styling, but this keeps
 * input-group inputs looking consistent during validation
 */
.input-group .custom-range:focus {
    background-color: #fff;
    border-color: #80bdff;
    outline: 0;
    box-shadow: 0 0 0 .2rem rgba(0,123,255,.25);
}

Results:

An alternative to using the borders of .custom-range that is not inside an .input-group, would be to change the background color of the track (maybe use the .alert-danger and .alert-success background or border colors), and to color the range handle to match validation.

[tmorehouse]

And here is what sizing would look like inside an input-group:

[tmorehouse]

Another alternative would be to style the range thumb based on state (long with the track colored):

[ysds]

In general, range inputs are always valid and no invalid state. In what situations can those styles be used? Also see my comment https://github.com/twbs/bootstrap/issues/27354#issuecomment-434665633.

[tmorehouse]

There are situations where the DOM prop (element.value) can be set via JS to a value out or range, which would be invalid (although the range will reject the value, but your data model may retain the invalid value).

One might want the range to change state colors when slid to close to a threshold (as in a warning), or a previously set range value is now no longer valid (and one would want to set the range as .is-invalid)

Plus, currently range inputs suck the big wazoo when placed into .input-groups (and this suggestion covers that as well). This is how range inputs look currently in input groups (compared to a text input):

When they should look like this:

[ysds]

There are situations where the DOM prop (element.value) can be set via JS to a value out or range, which would be invalid.

JS can’t set element.value out of range. Try it :)

[tmorehouse]

But, one may still want to apply .is-valid or .is-invalid for server side (or JS client-side) validation, or set .setCustomValidity() / .checkValidity() / .reportValidity() (client-side), and there are no styles for that currently.

What are your opinions on .custom-range inside input groups?

[mdo]

I'm a no on the input group—input groups were always designed for textual inputs first and foremost. In general I don't see much usage of range inputs already, and putting them inside an input group feels premature at this point. I like the min/max demo, but not enough to see it added :).

[tmorehouse]

I would find it handy to have an input group with a range input and an append showing the current value (if using something like Vue/React/Angular to dynamically show the value as the slider is shown), or mixing a range input with a number input (so a user could either type in a value, or slide the value. I can see several use cases for this.

[tmorehouse]

@mdo Adding support for range inside input group would require the following modifications (32 lines at most) to /scss/_input-group.scss:

.input-group {
  /* ... */

  > .form-control,
  > .form-control-plaintext,
  > .custom-select,
  > .custom-range, // ⇐ Add this line
  > .custom-file {
    /* .... */

    + .form-control,
    + .custom-select,
    + .custom-range, // ⇐ Add this line
    + .custom-file { 
      margin-left: -$input-border-width;
    }
    /* .... */
  }

  > .form-control:focus,
  > .custom-select:focus,
  > .custom-range:focus, // ⇐ add this line
  > .custom-file .custom-file-input:focus ~ .custom-file-label {
    z-index: 3;
  }

  /* ... */

  > .form-control,
  > .custom-range, // ⇐ add this line
  > .custom-select {
    &:not(:last-child) { @include border-right-radius(0); }
    &:not(:first-child) { @include border-left-radius(0); }
  }

  // ⇓ New section ⇓
  // Specific for custom-range inside input group (building off of form-control styles)
  // to give the range input a similar look/feel to other input-group inputs 
  > .custom-range {
    height: $input-height;
    padding: 0 $input-padding-x;
    background-color: $input-bg;
    background-clip: padding-box;
    border: $input-border-width solid $input-border-color;
    height: $input-height;

    @if $enable-rounded {
      border-radius: $input-border-radius;
    } @else {
      border-radius: 0;
    }

    @include box-shadow($input-box-shadow);
    @include transition($input-transition);
    @include form-control-focus(); // ⇐ can leave out to not style border on focus

    &:disabled,
    &[readonly] {
      background-color: $input-disabled-bg;
    }
  }

  /* ... */
}

/* ... */

// ⇓ New additions to Sizing section ⇓
.input-group-lg > .custom-range {
  height: $input-height-lg;
  padding: 0 $input-padding-x-lg; // ⇐ can leave out to keep $input-padding-x
  @include border-radius($input-border-radius-lg);
}
.input-group-sm > .custom-range {
  height: $input-height-sm;
  padding: 0 $input-padding-x-sm // ⇐ can leave out to keep $input-padding-x
  @include border-radius($input-border-radius-sm);
}

[ysds]

I understood about a scenario with server side validation. But I feel strange about the border around a slider control. I prefer without borders style.

https://codepen.io/anon/pen/OBKGKY

[Joyrex]

Shouldn't the slider produce a tooltip showing the value of the current control position?

[tmorehouse]

Here is an example usage of range in an input-group:

The data model of both the range and number input would be tied together. Changing one, changes the other.

<div class="input-group input-group-sm">
  <div class="input-group-prepend">
    <div class="input-group-text">Range:</div>
  </div>
  <input type="range" class="custom-range w-75" min="0" max="100" step="1">
  <input type="number" class="form-control" min="0" max="100" step="1">
</div>

But currently this is not possible with .custom-range

[mdo]

If there's a strong enough case here for validation, I wouldn't mind seeing a PR for it :). Per my last comment though, closing this out as I don't think we need to be building these kind of intermixed components—each addition makes input groups more difficult to maintain.

[tmorehouse]

I'll see what I can do for a minimal PR that doesn't disrupt too much, at least for supporting range inside an input group (not necessarily validation, as that involves a bit more work/maintenance)

[tmorehouse]

I could create a separate PR for validation, which would just handle changing the thumb colour and track colour.

[mdo]

Sounds good! Appreciate that :).

[tmorehouse]

No prob... I'll see what I can do before heading off for the holidays next Wednesday.

We actually have custom SCSS that we use for Bootstrap-Vue that generates the validaton and input group stuff... but its based on v4.1.3 SCSS so will need to check for changes/tweaks that need to be done to handle v4.2 SCSS