Tag: MultiThumb

Let’s Make a Multi-Thumb Slider That Calculates The Width Between Thumbs

HTML has an <input type="range">, which is, you could argue, the simplest type of proportion slider. Wherever the thumb of that slider ends up could represent a proportion of whatever is before and whatever is after it (using the value and max attributes). Getting fancier, it’s possible to build a multi-thumb slider. But we’ve got another thing in mind today… a proportion slider with multiple thumbs, and sections that cannot overlap.

Here’s what we’ll be building today:

This is a slider, but not just any slider. It’s a proportion slider. Its various sections must all add up to 100% and the user can adjust the different sections in it.

Why would you need such a thing ? 

Maybe you want to build a budget app where a slider like this would consist of your various planned expenses:

I needed something like this to make an anime movie suggestions platform. While researching UX patterns, I noticed that other anime movie suggestion websites have this sort of thing where you select tags to get movie recommendations. That’s cool and all, but how much cooler would it be to add weight to those tags so that recommendations for a tag with a larger weight are prioritized over other tags with lighter weights. I looked around for other ideas, but didn’t find much.

So I built this! And believe it or not, making it is not that complicated. Let me take you through the steps.

The static slider

We’ll be building this in React and TypeScript. That’s not required though. The concepts should port to vanilla JavaScript or any other framework.

Let’s make this slider using dynamic data for the start. We’ll keep the different sections in a variable array with the name and color of each section. 

const _tags = [   {     name: "Action",     color: "red"   },   {     name: "Romance",     color: "purple"   },   {     name: "Comedy",     color: "orange"   },   {     name: "Horror",     color: "black"   } ];

The width of each tag section is controlled by an array of percentages that add up to 100%. This is done by using the Array.Fill() method to initialize the state of each width:

const [widths, setWidths] = useState<number[]>(new Array(_tags.length).fill(100 / _tags.length))

Next, we’ll create a component to render a single tag section:

interface TagSectionProps {   name: string   color: string   width: number } 
 const TagSection = ({ name, color, width }: TagSectionProps) => {   return <div     className='tag'     style={{ ...styles.tag, background: color, width: width + '%' }} >     <span style={styles.tagText}>{name}</span>    <div      style={styles.sliderButton}      className='slider-button'>              <img src={"https://assets.codepen.io/576444/slider-arrows.svg"} height={'30%'} />     </div>   </div > }

Then we’ll render all of the sections by mapping through the _tags array and return the TagSection component we created above:

const TagSlider = () => {   const [widths, setWidths] = useState<number[]>((new Array(_tags.length).fill(100 / _tags.length)))   return <div     style={{       width: '100%',       display: 'flex'     }}>     {     _tags.map((tag, index) => <TagSection       width={widths[index]}       key={index}       name={tag.name}       color={tag.color}     />)     }   </div> }

To make rounded borders and hide the last slider button, let’s the :first-of-type and :last-of-type pseudo-selectors in CSS:

.tag:first-of-type {   border-radius: 50px 0px 0px 50px; } .tag:last-of-type {   border-radius: 0px 50px 50px 0px; } .tag:last-of-type>.slider-button {   display:none !important; }

Here’s where we are so far. Note the slider handles don’t do anything yet! We’ll get to that next.

Adjustable slider sections

We want the slider sections to adjust move when the slider buttons are dragged with either a mouse cursor or touch, We’ll do that by making sure the section width changes correspond to how much the slider buttons have been dragged. That requires us to answer a few questions:

  1. How do we get the cursor position when the slider button is clicked?
  2. How do we get the cursor position while the slider button is being dragged?
  3. How can we make the width of the tag section correspond to how much the tag section button has been dragged ?

One by one…

How do we get the cursor position when the slider button is clicked?

Let’s add an onSliderSelect event handler to the TagSectionProps interface:

interface TagSectionProps {   name: string;   color: string;   width: number;   onSliderSelect: (e: React.MouseEvent<HTMLDivElement, MouseEvent>) => void; }

The onSliderSelect event handler is attached to the onPointerDown event of the TagSection component:

const TagSection = ({   name,   color,   width,   onSliderSelect // Highlight }: TagSectionProps) => {   return (     <div       className="tag"       style={{         ...styles.tag,         background: color,         width: width + "%"         }}     >       <span style={styles.tagText}>{name}</span>       <span style={{ ...styles.tagText, fontSize: 12 }}>{width + "%"}</span>          <div         style={styles.sliderButton}         onPointerDown={onSliderSelect}         className="slider-button"       >       <img src={"https://animesonar.com/slider-arrows.svg"} height={"30%"} />       </div>     </div>   ); };

We use onPointerDown instead of onMouseDown to catch both mouse and touch screen events. Here’s more information about that. 

We’re using e.pageX in the onSliderSelect prop function to get the cursor’s position when the slider’s button has been clicked:

<TagSection   width={widths[index]}   key={index}   name={tag.name}   onSliderSelect={(e) => {     const startDragX = e.pageX;   }} />

One down!

How do we get the cursor position while the slider button is being dragged?

Now we need to add an event listener to listen for the drag events, pointermove and touchmove. We’ll use these events to cover mouse cursor and touch movements. The section widths need to stop updating once the user’s finger raises from the screen (thus ending the drag): 

window.addEventListener("pointermove", resize); window.addEventListener("touchmove", resize); 
 const removeEventListener = () => {   window.removeEventListener("pointermove", resize);   window.removeEventListener("touchmove", resize); } 
 const handleEventUp = (e: Event) => {   e.preventDefault();   document.body.style.cursor = "initial";   removeEventListener(); } 
 window.addEventListener("touchend", handleEventUp); window.addEventListener("pointerup", handleEventUp);

The resize function gives the X coordinate of the cursor while the slider button is being dragged:

const resize = (e: MouseEvent & TouchEvent) => {   e.preventDefault();   const endDragX = e.touches ? e.touches[0].pageX : e.pageX }

When the resize function is triggered by a touch event, e.touches is an array value — otherwise, it’s null, in which case endDragX takes the value of e.pageX

How can we make the width of the tag section correspond to how much the tag section button has been dragged?

To change the width percentages of the various tag sections, let’s get the distance the cursor moves in relation to the entire width of the slider as a percentage. From there, we’ll assign that value to the tag section.

First, we need to get the refof TagSlider using React’s useRef hook:

const TagSlider = () => { const TagSliderRef = useRef<HTMLDivElement>(null);   // TagSlider   return (     <div       ref={TagSliderRef} // ...

Now let’s figure out the width of the slider by using its reference to get the offsetWidth property, which returns the layout width of an element as an integer:

onSliderSelect={(e) => {   e.preventDefault();   document.body.style.cursor = 'ew-resize'; 
   const startDragX = e.pageX;   const sliderWidth = TagSliderRef.current.offsetWidth; }};

Then we calculate the percentage distance the cursor moved relative to the entire slider:

const getPercentage = (containerWidth: number, distanceMoved: number) => {   return (distanceMoved / containerWidth) * 100; }; 
 const resize = (e: MouseEvent & TouchEvent) => {   e.preventDefault();   const endDragX = e.touches ? e.touches[0].pageX : e.pageX;   const distanceMoved = endDragX - startDragX;   const percentageMoved = getPercentage(sliderWidth, distanceMoved); }

Finally, we can assign the newly calculated section width to its index on the _widths state variable:

const percentageMoved = getPercentage(sliderWidth, distanceMoved); const _widths = widths.slice(); const prevPercentage = _widths[index]; const newPercentage = prevPercentage + percentageMoved 
 _widths[index] = newPercentage; setWidths(_widths);

But this isn’t the end! The other sections aren’t changing widths and the percentages can wind up being negative or adding up to more than 100%. Not to mention, the sum of all section widths isn’t always equal to 100% because we haven’t applied a restriction that prevents the overall percentage from changing.

Fixing up the other sections

Let’s make sure the width of one section changes when the section next to it changes.

const nextSectionNewPercentage = percentageMoved < 0    ? _widths[nextSectionIndex] + Math.abs(percentageMoved)   : _widths[nextSectionIndex] - Math.abs(percentageMoved)

This has the effect of reducing the width of the neighboring section if the section increases and vice-versa. We can even shorten it:

const nextSectionNewPercentage = _widths[nextSectionIndex] - percentageMoved

Adjusting a section percentage should only affect its neighbor to the right. This means that the maximum value of a given section maximum percentage should be its width plus the width of its neighbor width when it’s allowed to take up the entire neighbor’s space.

We can make that happen by calculating a maximum percentage value:

const maxPercent = widths[index] + widths[index+1]

To prevent negative width values, let’s restrict the widths to values greater than zero but less than the max percentage: 

const limitNumberWithinRange = (value: number, min: number, max: number):number => {   return Math.min(Math.max(value,min),max) }

The limitNumberWithinRange function both prevents negative values and instances where the sum of sections results ina value higher than the maximum percentage. (Hat tip to this StavkOverflow thread.)

We can use this function for the width of the current section and its neighbor:

const currentSectionWidth = limitNumberWithinRange(newPercentage, 0, maxPercent) _widths[index] = currentSectionWidth 
 const nextSectionWidth = limitNumberWithinRange(nextSectionNewPercentage, 0, maxPercent); _widths[nextSectionIndex] = nextSectionWidth;

Extra touches

Right now, the slider calculates the width of each section as a percentage of the entire container to some crazy decimal. That’s super precise, but not exactly useful for this sort of UI. If we want to work with whole numbers instead of decimals, we can do something like this:

const nearestN = (N: number, number: number) => Math.ceil(number / N) * N; const percentageMoved = nearestN(1, getPercentage(sliderWidth, distanceMoved))

This function approximates the second parameter’s value to the nearest N (specified by the first parameter). Setting  N to 1 like the this example has the effect of making the percentage change in whole numbers instead of tiny incremental decimals.

Another nice to touch is consider additional handling for sections with a zero percentage value. Those should probably be removed from the slider altogether since they no longer take up any proportion of the overall width. We can stop listening for events on those sections:

if (tags.length > 2) {   if (_widths[index] === 0) {      _widths[nextSectionIndex] = maxPercent;     _widths.splice(index, 1);     setTags(tags.filter((t, i) => i !== index));     removeEventListener();   }   if (_widths[nextSectionIndex] === 0) {     _widths[index] = maxPercent;     _widths.splice(nextSectionIndex, 1);     setTags(tags.filter((t, i) => i !== nextSectionIndex));     removeEventListener();   } }

Voila!

Here’s the final slider:

The post Let’s Make a Multi-Thumb Slider That Calculates The Width Between Thumbs appeared first on CSS-Tricks.

CSS-Tricks

, , , , , ,

Multi-Thumb Sliders: General Case

The first part of this two-part series detailed how we can get a two-thumb slider. Now we’ll look at a general multi-thumb case, but with a different and better technique for creating the fills in between the thumbs. And finally, we’ll dive into the how behind the styling a realistic 3D-looking slider and a flat one.

Article Series:

  1. Multi-Thumb Sliders: Particular Two-Thumb Case
  2. Multi-Thumb Sliders: General Case (This Post)

A better, more flexible approach

Let’s say that, on a wrapper pseudo-element that covers the same area as the range inputs, we stack left-to–right linear-gradient() layers corresponding to each thumb. Each gradient layer is fully opaque (i.e. the alpha is 1) from the track minimum up to the thumb’s mid-line, after which it’s fully transparent (i.e. the alpha is 0).

Note that the RGB values don’t matter because all we care about are the alpha values. I personally use the red (for the fully opaque part) and transparent keywords in the code because they do the job with the least amount of characters.

How do we compute the gradient stop positions where we go from fully opaque to fully transparent? Well, these positions are always situated between a thumb radius from the left edge and a thumb radius from the right edge, so they are within a range that’s equal to the useful width (the track width, minus the thumb diameter).

This means we first add a thumb radius.Then we compute the progress by dividing the difference between the current thumb’s position and the minimum to the difference (--dif) between the maximum and the minimum. This progress value is a number in the [0, 1] interval — that’s 0 when the current thumb position is at the slider’s minimum, and 1 when the current thumb position is at the slider’s maximum. To get where exactly along that useful width interval we are, we multiply this progress value with the useful width.

The position we’re after is the sum between these two length values: the thumb radius and how far we are across the useful width interval.

The demo below allows us to see how everything looks stacked up in the 2D view and how exactly the range inputs and the gradients on their parent’s pseudo-element get layered in the 3D view. It’s also interactive, so we can drag the slider thumbs and see how the corresponding fill (which is created by a gradient layer on its parent’s pseudo-element) changes.

See the Pen by thebabydino (@thebabydino) on CodePen.

The demo is best viewed in Chrome and Firefox.

Alright, but simply stacking these gradient layers doesn’t give us the result we’re after.

The solution here is to make these gradients mask layers and then XOR them (more precisely, in the case of CSS masks, this means to XOR their alphas).

If you need a refresher on how XOR works, here’s one: given two inputs, the output of this operation is 1 if the input values are different (one of them is 1 and the other one is 0) and 0 if the input values are identical (both of them are 0 or both of them are 1)

The truth table for the XOR operation looks as follows:

Inputs Output
A B
0 0 0
0 1 1
1 0 1
1 1 0

You can also play with it in the following interactive demo, where you can toggle the input values and see how the output changes:

See the Pen by thebabydino (@thebabydino) on CodePen.

In our case, the input values are the alphas of the gradient mask layers along the horizontal axis. XOR-ing multiple layers means doing so for the first two from the bottom, then XOR-ing the third from the bottom with the result of the previous XOR operation and so on. For our particular case of left-to-right gradients with an alpha equal to 1 up to a point (decided by the corresponding thumb value) and then 0, it looks as illustrated below (we start from the bottom and work our way up):

SVG illustration. Illustrates the process described in the following three paragraphs.
How we XOR the gradient layer alphas (Demo).

Where both layers from the bottom have an alpha of 1, the resulting layer we get after XOR-ing them has an alpha of 0. Where they have different alpha values, the resulting layer has an alpha of 1. Where they both have an alpha of 0, the resulting layer has an alpha of 0.

Moving up, we XOR the third layer with the resulting layer we got at the previous step. Where both these layers have the same alpha, the alpha of the layer that results from this second XOR operation is 0. Where they have different alphas, the resulting alpha is 1.

Similarly, we then XOR the fourth layer from the bottom with the layer resulting from the second stage XOR operation.

In terms of CSS, this means using the exclude value for the standard mask-composite and the xor value for the non-standard -webkit-mask-composite. (For a better understanding of mask compositing, check out the crash course.)

This technique gives us exactly the result we want while also allowing us to use a single pseudo-element for all the fills. It’s also a technique that works for any number of thumbs. Let’s see how we can put it into code!

In order to keep things fully flexible, we start by altering the Pug code such that it allows to add or remove a thumb and update everything else accordingly by simply adding or removing an item from an array of thumb objects, where every object contains a value and a label (which will be only for screen readers):

- let min = -50, max = 50; - let thumbs = [ -   { val: -15, lbl: 'Value A' },  -   { val: 20, lbl: 'Value B' },  -   { val: -35, lbl: 'Value C' },  -   { val: 45, lbl: 'Value D' } - ]; - let nv = thumbs.length;  .wrap(role='group' aria-labelledby='multi-lbl'        style=`$ {thumbs.map((c, i) => `--v$ {i}: $ {c.val}`).join('; ')};               --min: $ {min}; --max: $ {max}`)   #multi-lbl Multi thumb slider:     - for(let i = 0; i < nv; i++)       label.sr-only(for=`v$ {i}`) #{thumbs[i].lbl}       input(type='range' id=`v$ {i}` min=min value=thumbs[i].val max=max)       output(for=`v$ {i}` style=`--c: var(--v$ {i})`)

In the particular case of these exact four values, the generated markup looks as follows:

<div class='wrap' role='group' aria-labelledby='multi-lbl'       style='--v0: -15; --v1: 20; --v2: -35; --v3: 45; --min: -50; --max: 50'>   <div id='multi-lbl'>Multi thumb slider:</div>   <label class='sr-only' for='v0'>Value A</label>   <input type='range' id='v0' min='-50' value='-15' max='50'/>   <output for='v0' style='--c: var(--v0)'></output>   <label class='sr-only' for='v1'>Value B</label>   <input type='range' id='v1' min='-50' value='20' max='50'/>   <output for='v1' style='--c: var(--v1)'></output>   <label class='sr-only' for='v2'>Value C</label>   <input type='range' id='v2' min='-50' value='-35' max='50'/>   <output for='v2' style='--c: var(--v2)'></output>   <label class='sr-only' for='v3'>Value D</label>   <input type='range' id='v3' min='-50' value='45' max='50'/>   <output for='v3' style='--c: var(--v3)'></output> </div>

We don’t need to add anything to the CSS or the JavaScript for this to give us a functional slider where the <output> values get updated as we drag the sliders. However, having four <output> elements while the wrapper’s grid still has two columns would break the layout. So, for now, we remove the row introduced for the <output> elements, position these elements absolutely and only make them visible when the corresponding <input> is focused. We also remove the remains of the previous solution that uses both pseudo-elements on the wrapper.

.wrap {   /* same as before */   grid-template-rows: max-content #{$ h}; /* only 2 rows now */    &::after {     background: #95a;     // content: ''; // don't display for now     grid-column: 1/ span 2;     grid-row: 3;   } }  input[type='range'] {   /* same as before */   grid-row: 2; /* last row is second row now */ }  output {   color: transparent;   position: absolute;   right: 0; 	   &::after {     content: counter(c);     counter-reset: c var(--c);   } }

We’ll be doing more to prettify the result later, but for now, here’s what we have:

See the Pen by thebabydino (@thebabydino) on CodePen.

Next, we need to get those thumb to thumb fills. We do this by generating the mask layers in the Pug and putting them in a --fill custom property on the wrapper.

//- same as before - let layers = thumbs.map((c, i) => `linear-gradient(90deg, red calc(var(--r) + (var(--v$ {i}) - var(--min))/var(--dif)*var(--uw)), transparent 0)`);  .wrap(role='group' aria-labelledby='multi-lbl'    style=`$ {thumbs.map((c, i) => `--v$ {i}: $ {c.val}`).join('; ')};      --min: $ {min}; --max: $ {max};     --fill: $ {layers.join(', ')}`)   // - same as before

The generated HTML for the particular case of four thumbs with these values can be seen below. Note that this gets altered automatically if we add or remove items from the initial array:

<div class='wrap' role='group' aria-labelledby='multi-lbl'    style='--v0: -15; --v1: 20; --v2: -35; --v3: 45;      --min: -50; --max: 50;     --fill:        linear-gradient(90deg,          red calc(var(--r) + (var(--v0) - var(--min))/var(--dif)*var(--uw)),          transparent 0),        linear-gradient(90deg,          red calc(var(--r) + (var(--v1) - var(--min))/var(--dif)*var(--uw)),          transparent 0),        linear-gradient(90deg,          red calc(var(--r) + (var(--v2) - var(--min))/var(--dif)*var(--uw)),          transparent 0),        linear-gradient(90deg,          red calc(var(--r) + (var(--v3) - var(--min))/var(--dif)*var(--uw)),          transparent 0)'>   <div id='multi-lbl'>Multi thumb slider:</div>   <label class='sr-only' for='v0'>Value A</label>   <input type='range' id='v0' min='-50' value='-15' max='50'/>   <output for='v0' style='--c: var(--v0)'></output>   <label class='sr-only' for='v1'>Value B</label>   <input type='range' id='v1' min='-50' value='20' max='50'/>   <output for='v1' style='--c: var(--v1)'></output>   <label class='sr-only' for='v2'>Value C</label>   <input type='range' id='v2' min='-50' value='-35' max='50'/>   <output for='v2' style='--c: var(--v2)'></output>   <label class='sr-only' for='v3'>Value D</label>   <input type='range' id='v3' min='-50' value='45' max='50'/>   <output for='v3' style='--c: var(--v3)'></output> </div>

Note that this means we need to turn the Sass variables relating to dimensions into CSS variables and replace the Sass variables in the properties that use them:

.wrap {   /* same as before */   --w: 20em;   --h: 4em;   --d: calc(.5*var(--h));   --r: calc(.5*var(--d));   --uw: calc(var(--w) - var(--d));   background: linear-gradient(0deg, #ccc var(--h), transparent 0);   grid-template: max-content var(--h)/ var(--w);   width: var(--w); }

We set our mask Oo the wrapper’s ::after pseudo-element:

.wrap {   /* same as before */      &::after {     content: '';     background: #95a;     grid-column: 1/ span 2;     grid-row: 2;      /* non-standard WebKit version */     -webkit-mask: var(--fill);     -webkit-mask-composite: xor;      /* standard version, supported in Firefox */     mask: var(--fill);     mask-composite: exclude;   } }

Now we have exactly what we want and the really cool thing about this technique is that all we need to do to change the number of thumbs is add or remove thumb objects (with a value and a label for each) to the thumbs array in the Pug code — absolutely nothing else needs to change!

See the Pen by thebabydino (@thebabydino) on CodePen.

Prettifying tweaks

What we have so far is anything but a pretty sight. So let’s start fixing that!

Option #1: a realistic look

Let’s say we want to achieve the result below:

Screenshot. The track and fill are the same height as the thumbs. The track looks carved into the page, while the fill and the thumb have a convex look inside it.
The realistic look we’re after.

A first step would be to make the track the same height as the thumb and round the track ends. Up to this point, we’ve emulated the track with a background on the .wrap element. While it’s technically possible to emulate a track with rounded ends by using layered linear and radial gradients, it’s really not the best solution, especially when the wrapper still has a free pseudo-element (the ::before).

.wrap {   /* same as before */   --h: 2em;   --d: var(--h);      &::before, &::after {     border-radius: var(--r);     background: #ccc;     content: '';     grid-column: 1/ span 2;     grid-row: 2;   }      &::after {     background: #95a;      /* non-standard WebKit version */     -webkit-mask: var(--fill);     -webkit-mask-composite: xor;      /* standard version, supported in Firefox */     mask: var(--fill);     mask-composite: exclude;   } }

See the Pen by thebabydino (@thebabydino) on CodePen.

Using ::before to emulate the track opens up the possibility of getting a slightly 3D look:

<pre rel="SCSS"><code class="language-scss">.wrap {   /* same as before */      &::before, &::after {     /* same as before */     box-shadow: inset 0 2px 3px rgba(#000, .3);   }      &::after {     /* same as before */     background:        linear-gradient(rgba(#fff, .3), rgba(#000, .3))       #95a;   } }

I’m by no means a designer, so those values could probably be tweaked for a better looking result, but we can already see a difference:

See the Pen by thebabydino (@thebabydino) on CodePen.

This leaves us with a really ugly thumb, so let’s fix that part as well!

We make use of the technique of layering multiple backgrounds with different background-clip (and background-origin) values.

@mixin thumb() {   border: solid calc(.5*var(--r)) transparent;   border-radius: 50%; /* make circular */   box-sizing: border-box; /* different between Chrome & Firefox */   /* box-sizing needed now that we have a non-zero border */   background:      linear-gradient(rgba(#000, .15), rgba(#fff, .2)) content-box,      linear-gradient(rgba(#fff, .3), rgba(#000, .3)) border-box,      currentcolor;   pointer-events: auto;   width: var(--d); height: var(--d); }

I’ve described this technique in a lot of detail in an older article. Make sure you check it out if you need a refresher!

The above bit of code would do close to nothing, however, if the currentcolor value is black (#000) which it is right now. Let’s fix that and also change the cursor on the thumbs to something more fitting:

input[type='range'] {   /* same as before */   color: #eee;   cursor: grab;      &:active { cursor: grabbing; } }

The result is certainly more satisfying than before:

See the Pen by thebabydino (@thebabydino) on CodePen.

Something else that really bothers me is how close the label text is to the slider. We can fix this by introducing a grid-gap on the wrapper:

.wrap {   /* same as before */   grid-gap: .625em; }

But the worst problem we still have are those absolutely positioned outputs in the top right corner. The best way to fix this is to introduce a third grid row for them and move them with the thumbs.

The position of the thumbs is computed in a similar manner to that of the sharp stops of the gradient layers we use for the fill mask.

Initially, we place the left edge of the outputs along the vertical line that’s a thumb radius --r away from the left edge of the slider. In order to middle align the outputs with this vertical line, we translate them back (to the left, in the negative direction of the x-axis, so we need a minus sign) by half of their width (50%, as percentage values in translate() functions are relative to the dimensions of the element the transform is applied to).

In order to move them with the thumbs, we subtract the minimum value (--min) from the current value of the corresponding thumb (--c), divide this difference by the difference (--dif) between the maximum value (--max) and the minimum value (--min). This gives us a progress value in the [0, 1] interval. We then multiply this value with the useful width (--uw), which describes the real range of motion.

.wrap {   /* same as before */   grid-template-rows: max-content var(--h) max-content; }  output {   background: currentcolor;   border-radius: 5px;   color: transparent;   grid-column: 1;   grid-row: 3;   margin-left: var(--r);   padding: 0 .375em;   transform: translate(calc((var(--c) - var(--min))/var(--dif)*var(--uw) - 50%));   width: max-content;      &::after {     color: #fff;     content: counter(c);     counter-reset: c var(--c);   } }

See the Pen by thebabydino (@thebabydino) on CodePen.

This looks much better at a first glance. However, a closer inspection reveals that we still have a bunch of problems.

The first one is that overflow: hidden cuts out a bit of the <output> elements when we get to the track end.

In order to fix this, we must understand what exactly overflow: hidden does. It cuts out everything outside an element’s padding-box, as illustrated by the interactive demo below, where you can click the code to toggle the CSS declaration.

See the Pen by thebabydino (@thebabydino) on CodePen.

This means a quick fix for this issue is to add a big enough lateral padding on the wrapper .wrap.

padding: 0 2em;

We’re styling our multi-thumb slider in isolation here, but, in reality, it probably won’t be the only thing on a page, so, if spacing is limited, we can invert that lateral padding with a negative lateral margin.

If the nearby elements still have the default have position: static, the fact that we’ve relatively positioned the wrapper should make the outputs go on top of what they overlap, otherwise, tweaking the z-index on the .wrap should do it.

The bigger problem is that this technique we’ve used results in some really weird-looking <output> overlaps when were dragging the thumbs.

Increasing the z-index when the <input> is focused on the corresponding <output> as well solves the particular problem of the <output> overlaps:

input[type='range'] {   &:focus {     outline: solid 0 transparent; 		     &, & + output {       color: darkorange;       z-index: 2;     }   } }

However, it does nothing for the underlying issue and this becomes obvious when we change the background on the body, particularly if we change it to an image one, as this doesn’t allow the <output> text to hide in it anymore:

See the Pen by thebabydino (@thebabydino) on CodePen.

This means we need to rethink how we hide the <output> elements in the normal state and how we reveal them in a highlight state, such as :focus. We also want to do this without bloating our CSS.

The solution is to use the technique I described about a year ago in the “DRY Switching with CSS Variables” article: use a highlight --hl custom property where the value is 0 in the normal state and 1 in a highlight state (:focus). We also compute its negation (--nothl).

* {   --hl: 0;   --nothl: calc(1 - var(--hl));   margin: 0;   font: inherit }

As it is, this does nothing yet. The trick is to make all properties that we want to change in between the two states depend on --hl and, if necessary, its negation (code>–nothl).

$ hlc: #f90;  @mixin thumb() {   /* same as before */   background-color: $ hlc; }  input[type='range'] {   /* same as before */   filter: grayScale(var(--nothl));   z-index: calc(1 + var(--hl));      &:focus {     outline: solid 0 transparent;          &, & + output { --hl: 1; }   } }  output {   /* same grid placement */   margin-left: var(--r);   max-width: max-content;   transform: translate(calc((var(--c) - var(--min))/var(--dif)*var(--uw))); 	   &::after {     /* same as before */     background:        linear-gradient(rgba(#fff, .3), rgba(#000, .3))       $ hlc;     border-radius: 5px;     display: block;     padding: 0 .375em;     transform: translate(-50%) scale(var(--hl));   } }

See the Pen by thebabydino (@thebabydino) on CodePen.

We’re almost there! We can also add transitions on state change:

$ t: .3s;  input[type='range'] {   /* same as before */   transition: filter $ t ease-out; }  output::after {   /* same as before */   transition: transform $ t ease-out; }

See the Pen by thebabydino (@thebabydino) on CodePen.

A final improvement would be to grayscale() the fill if none of the thumbs are focused. We can do this by using :focus-within on our wrapper:

.wrap {   &::after {     /* same as before */     filter: Grayscale(var(--nothl));     transition: filter $ t ease-out;   } 	   &:focus-within { --hl: 1; } }

And that’s it!

See the Pen by thebabydino (@thebabydino) on CodePen.

Option #2: A flat look

Let’s see how we can get a flat design. For example:

Screenshot. All slider components are flat, no shadows or gradients. The track and fill are narrower than the thumbs and middle aligned with these. The track has a striped background. The thumbs are scaled down and reveal circular holes in the track around them in their unfocused state.
The flat look we’re after.

The first step is to remove the box shadows and gradients that give our previous demo a 3D look and make the track background a repeating gradient.:

See the Pen by thebabydino (@thebabydino) on CodePen.

The size change of the thumb on :focus can be controlled with a scaling transform with a factor that depends on the highlight switch variable (--hl).

@mixin thumb() {   /* same as before */   transform: scale(calc(1 - .5*var(--nothl)));   transition: transform $ t ease-out; }

See the Pen by thebabydino (@thebabydino) on CodePen.

But what about the holes in the track around the thumbs?

The mask compositing technique is extremely useful here. This involves layering radial gradients to create discs at every thumb position and, after we’re done with them, invert (i.e. compositing with a fully opaque layer) the result to turn those discs into holes.

SVG illustration. Shows that XOR-ing a bunch of radial-gradient() layers gives us a layer with opaque discs and everything else transparent and when, we xor this resulting layer with a fully opaque one, this fully opaque layer acts as an inverter, turning the discs into transparent holes in an otherwise fully opaque layer.
How we XOR the gradient layer alphas (Demo).

This means altering the Pug code a bit so that we’re generating the list of radial gradients that create the discs corresponding to each thumb. In turn, we’ll invert those in the CSS:

//- same as before - let tpos = thumbs.map((c, i) => `calc(var(--r) + (var(--v$ {i}) - var(--min))/var(--dif)*var(--uw))`); - let fill = tpos.map(c => `linear-gradient(90deg, red $ {c}, transparent 0)`); - let hole = tpos.map(c => `radial-gradient(circle at $ {c}, red var(--r), transparent 0)`)  .wrap(role='group' aria-labelledby='multi-lbl'    style=`$ {thumbs.map((c, i) => `--v$ {i}: $ {c.val}`).join('; ')};      --min: $ {min}; --max: $ {max};     --fill: $ {fill.join(', ')};      --hole: $ {hole.join(', ')}`)   // -same wrapper content as before

This generates the following markup:

<div class='wrap' role='group' aria-labelledby='multi-lbl'    style='--v0: -15; --v1: 20; --v2: -35; --v3: 45;      --min: -50; --max: 50;     --fill:        linear-gradient(90deg,          red calc(var(--r) + (var(--v0) - var(--min))/var(--dif)*var(--uw)),          transparent 0),        linear-gradient(90deg,          red calc(var(--r) + (var(--v1) - var(--min))/var(--dif)*var(--uw)),          transparent 0),         linear-gradient(90deg,           red calc(var(--r) + (var(--v2) - var(--min))/var(--dif)*var(--uw)),           transparent 0),         linear-gradient(90deg,           red calc(var(--r) + (var(--v3) - var(--min))/var(--dif)*var(--uw)),           transparent 0);       --hole:         radial-gradient(circle           at calc(var(--r) + (var(--v0) - var(--min))/var(--dif)*var(--uw)),           red var(--r), transparent 0),         radial-gradient(circle           at calc(var(--r) + (var(--v1) - var(--min))/var(--dif)*var(--uw)),           red var(--r), transparent 0),         radial-gradient(circle           at calc(var(--r) + (var(--v2) - var(--min))/var(--dif)*var(--uw)),           red var(--r), transparent 0),         radial-gradient(circle           at calc(var(--r) + (var(--v3) - var(--min))/var(--dif)*var(--uw)),           red var(--r), transparent 0)'>   <!-- same content as before --> </div>

In the CSS, we set a mask on both pseudo-elements and give a different value for each one. We also XOR the mask layers on them.

In the case of ::before, the mask is the list of radial-gradient() discs XOR-ed with a fully opaque layer (which acts as an inverter to turn the discs into circular holes). For ::after, it’s the list of fill linear-gradient() layers.

.wrap {   /* same as before */      &::before, &::after {     content: '';     /* same as before */          --mask: linear-gradient(red, red), var(--hole);      /* non-standard WebKit version */     -webkit-mask: var(--mask);     -webkit-mask-composite: xor;      /* standard version, supported in Firefox */     mask: var(--mask);     mask-composite: exclude;   } 	   &::after {     background: #95a;     --mask: var(--fill);   } }

See the Pen by thebabydino (@thebabydino) on CodePen.

The final step is to adjust the track, fill height, and middle align them vertically within their grid cell (along with the thumbs):

.wrap {   /* same as before */      &::before, &::after {     /* same as before */     align-self: center;     height: 6px;   } }

We now have our desired flat multi-thumb slider!

See the Pen by thebabydino (@thebabydino) on CodePen.

The post Multi-Thumb Sliders: General Case appeared first on CSS-Tricks.

CSS-Tricks

, , ,
[Top]

Multi-Thumb Sliders: Particular Two-Thumb Case

This is a concept I first came across a few years back when Lea Verou wrote an article on it. Multi-range sliders have sadly been removed from the spec since, but something else that has happened in the meanwhile is that CSS got better — and so have I, so I recently decided to make my own 2019 version.

In this two-part article, we’ll go through the how, step-by-step, first building an example with two thumbs, then identify the issues with it. We’ll solve those issues, first for the two-thumb case then, in part two, come up with a better solution for the multi-thumb case.

Note how the thumbs can pass each other and we can have any possible order, with the fills in between the thumbs adapting accordingly. Surprisingly, the entire thing is going to require extremely little JavaScript.

Article Series:

  1. Multi-Thumb Sliders: Particular Two-Thumb Case (This Post)
  2. Multi-Thumb Sliders: General Case (Coming Tomorrow!)

Basic structure

We need two range inputs inside a wrapper. They both have the same minimum and maximum value (this is very important because nothing is going to work properly otherwise), which we set as custom properties on the wrapper (--min and --max). We also set their values as custom properties (--a and --b).

- let min = -50, max = 50 - let a = -30, b = 20;  .wrap(style=`--a: $ {a}; --b: $ {b}; --min: $ {min}; --max: $ {max}`)   input#a(type='range' min=min value=a max=max)   input#b(type='range' min=min value=b max=max)

This generates the following markup:

<div class='wrap' style='--a: -30; --b: 20; --min: -50; --max: 50'>   <input id='a' type='range' min='-50' value='-30' max='50'/>   <input id='b' type='range' min='-50' value='20' max='50'/> </div>

Accessibility considerations

We have two range inputs and they should probably each have a <label>, but we want our multi-thumb slider to have a single label. How do we solve this issue? We can make the wrapper a <fieldset>, use its <legend> to describe the entire multi-thumb slider, and have a <label> that’s only visible to screen readers for each of our range inputs. (Thanks to Zoltan for this great suggestion.)

But what if we want to have a flex or grid layout on our wrapper? That’s something we probably want, as the only other option is absolute positioning and that comes with its own set of issues. Then we run into a Chromium issue where <fieldset> cannot be a flex or grid container.

To go around this, we use the following ARIA equivalent (which I picked up from this post by Steve Faulkner):

- let min = -50, max = 50 - let a = -30, b = 20;  .wrap(role='group' aria-labelledby='multi-lbl' style=`--a: $ {a}; --b: $ {b}; --min: $ {min}; --max: $ {max}`)   #multi-lbl Multi thumb slider:   label.sr-only(for='a') Value A:   input#a(type='range' min=min value=a max=max)   label.sr-only(for='b') Value B:   input#b(type='range' min=min value=b max=max)

The generated markup is now:

<div class='wrap' role='group' aria-labelledby='multi-lbl' style='--a: -30; --b: 20; --min: -50; --max: 50'>   <div id='multi-lbl'>Multi thumb slider:</div>   <label class='sr-only' for='a'>Value A:</label>   <input id='a' type='range' min='-50' value='-30' max='50'/>   <label class='sr-only' for='b'>Value B:</label>   <input id='b' type='range' min='-50' value='20' max='50'/> </div>

If we set an aria-label or an aria-labelledby attribute on an element, we also need to give it a role.

Basic styling

We make the wrapper a middle-aligned grid with two rows and one column. The bottom grid cell gets the dimensions we want for the slider, while the top one gets the same width as the slider, but can adjust its height according to the group label’s content.

$ w: 20em; $ h: 1em;  .wrap {   display: grid;   grid-template-rows: max-content $ h;   margin: 1em auto;   width: $ w; }

To visually hide the <label> elements, we absolutely position them and clip them to nothing:

.wrap {   // same as before   overflow: hidden; // in case <label> elements overflow   position: relative; }  .sr-only {   position: absolute;   clip-path: inset(50%); }

Some people might shriek about clip-path support, like how using it cuts out pre-Chromium Edge and Internet Explorer, but it doesn’t matter in this particular case! We’re getting to the why behind that in a short bit.

We place the sliders, one on top of the other, in the bottom grid cell:

input[type='range'] {   grid-column: 1;   grid-row: 2; }

See the Pen by thebabydino (@thebabydino) on CodePen.

We can already notice a problem however: not only does the top slider track show up above the thumb of the bottom one, but the top slider makes it impossible for us to even click and interact with the bottom one using a mouse or touch.

In order to fix this, we remove any track backgrounds and borders and highlight the track area by setting a background on the wrapper instead. We also set pointer-events: none on the actual <input> elements and then revert to auto on their thumbs.

@mixin track() {   background: none; /* get rid of Firefox track background */   height: 100%;   width: 100%; }  @mixin thumb() {   background: currentcolor;   border: none; /* get rid of Firefox thumb border */   border-radius: 0; /* get rid of Firefox corner rounding */   pointer-events: auto; /* catch clicks */   width: $ h; height: $ h; }  .wrap {   /* same as before */   background: /* emulate track with wrapper background */      linear-gradient(0deg, #ccc $ h, transparent 0); }  input[type='range'] {   &::-webkit-slider-runnable-track,    &::-webkit-slider-thumb, & { -webkit-appearance: none; }      /* same as before */   background: none; /* get rid of white Chrome background */   color: #000;   font: inherit; /* fix too small font-size in both Chrome & Firefox */   margin: 0;   pointer-events: none; /* let clicks pass through */      &::-webkit-slider-runnable-track { @include track; }   &::-moz-range-track { @include track; }      &::-webkit-slider-thumb { @include thumb; }   &::-moz-range-thumb { @include thumb; } }

Note that we’ve set a few more styles on the input itself as well as on the track and thumb in order to make the look consistent across the browsers that support letting clicks pass through the actual input elements and their tracks, while allowing them on the thumbs. This excludes pre-Chromium Edge and IE, which is why we haven’t included the -ms- prefix — there’s no point styling something that wouldn’t be functional in these browsers anyway. This is also why we can use clip-path to hide the <label> elements.

If you’d like to know more about default browser styles in order to understand what’s necessary to override here, you can check out this article where I take an in-depth look at range inputs (and where I also detail the reasoning behind using mixins here).

See the Pen by thebabydino (@thebabydino) on CodePen.

Alright, we now have something that looks functional. But in order to really make it functional, we need to move on to the JavaScript!

Functionality

The JavaScript is pretty straightforward. We need to update the custom properties we’ve set on the wrapper. (For an actual use case, they’d be set higher up in the DOM so that they’re also inherited by the elements whose styles that depend on them.)

addEventListener('input', e => {   let _t = e.target;   _t.parentNode.style.setProperty(`--$ {_t.id}`, +_t.value) }, false);

See the Pen by thebabydino (@thebabydino) on CodePen.

However, unless we bring up DevTools to see that the values of those two custom properties really change in the style attribute of the wrapper .wrap, it’s not really obvious that this does anything. So let’s do something about that!

Showing values

Something we can do to make it obvious that dragging the thumbs actually changes something is to display the current values. In order to do this, we use an output element for each input:

- let min = -50, max = 50 - let a = -30, b = 20;  .wrap(role='group' aria-labelledby='multi-lbl' style=`--a: $ {a}; --b: $ {b}; --min: $ {min}; --max: $ {max}`)   #multi-lbl Multi thumb slider:   label.sr-only(for='a') Value A:   input#a(type='range' min=min value=a max=max)   output(for='a' style='--c: var(--a)')   label.sr-only(for='b') Value B:   input#b(type='range' min=min value=b max=max)   output(for='b' style='--c: var(--b)')

The resulting HTML looks as follows:

<div class='wrap' role='group' aria-labelledby='multi-lbl' style='--a: -30; --b: 20; --min: -50; --max: 50'>   <div id='multi-lbl'>Multi thumb slider:</div>   <label class='sr-only' for='a'>Value A:</label>   <input id='a' type='range' min='-50' value='-30' max='50'/>   <output for='a' style='--c: var(--a)'></output>   <label class='sr-only' for='b'>Value B:</label>   <input id='b' type='range' min='-50' value='20' max='50'/>   <output for='b' style='--c: var(--b)'></output> </div>

We display the values in an ::after pseudo-element using a little counter trick:

output {   &::after {     counter-reset: c var(--c);     content: counter(c);   } }

See the Pen by thebabydino (@thebabydino) on CodePen.

It’s now obvious these values change as we drag the sliders, but the result is ugly and it has messed up the wrapper background alignment, so let’s add a few tweaks! We could absolutely position the <output> elements, but for now, we simply squeeze them in a row between the group label and the sliders:

.wrap {   // same as before   grid-template: repeat(2, max-content) #{$ h}/ 1fr 1fr; }  [id='multi-lbl'] { grid-column: 1/ span 2 }  input[type='range'] {   // same as before   grid-column: 1/ span 2;   grid-row: 3; }  output {   grid-row: 2;      &:last-child { text-align: right; }      &::after {     content: '--' attr(for) ': ' counter(c) ';'     counter-reset: c var(--c);   } }

Much better!

See the Pen by thebabydino (@thebabydino) on CodePen.

Setting separate :focus styles even gives us something that doesn’t look half bad, plus allows us to see which value we’re currently modifying.

input[type='range'] {   /* same as before */   z-index: 1;    &:focus {     z-index: 2;     outline: dotted 1px currentcolor;          &, & + output { color: darkorange }   } }

See the Pen by thebabydino (@thebabydino) on CodePen.

All we need now is to create the fill between the thumbs.

The tricky part

We can recreate the fill with an ::after pseudo-element on the wrapper, which we place on the bottom grid row where we’ve also placed the range inputs. This pseudo-element comes, as the name suggests, after the inputs, but it will still show up underneath them because we’ve set positive z-index values on them. Note that setting the z-index works on the inputs (without explicitly setting their position to something different from static) because they’re grid children.

The width of this pseudo-element should be proportional to the difference between the higher input value and the lower input value. The big problem here is that they pass each other and we have no way of knowing which has the higher value.

First approach

My first idea on how to solve this was by using width and min-width together. In order to better understand how this works, consider that we have two percentage values, --a and --b, and we want to make an element’s width be the absolute value of the difference between them.

Either one of the two values can be the bigger one, so we pick an example where --b is bigger and an example where --a is bigger:

<div style='--a: 30%; --b: 50%'><!-- first example, --b is bigger --></div> <div style='--a: 60%; --b: 10%'><!-- second example, --a is bigger --></div>

We set width to the second value (--b) minus the first (--a) and min-width to the first value (--a) minus the second one (--b).

div {   background: #f90;   height: 4em;   min-width: calc(var(--a) - var(--b));   width: calc(var(--b) - var(--a)); }

If the second value (--b) is bigger, then the width is positive (which makes it valid) and the min-width negative (which makes it invalid). That means the computed value is the one set via the width property. This is the case in the first example, where --b is 70% and --a is 50%. That means the width computes to 70% - 50% = 20%, while the min-width computes to 50% - 70% = -20%.

If the first value is bigger, then the width is negative (which makes it invalid) and the min-width is positive (which makes it valid), meaning the computed value is that set via the min-width property. This is the case in the second example, where --a is 80% and --b is 30%, meaning the width computes to 30% - 80% = -50%, while the min-width computes to 80% - 30% = 50%.

See the Pen by thebabydino (@thebabydino) on CodePen.

Applying this solution for our two thumb slider, we have:

.wrap {   /* same as before */   --dif: calc(var(--max) - var(--min));      &::after {     content: '';     background: #95a;     grid-column: 1/ span 2;     grid-row: 3;     min-width: calc((var(--a) - var(--b))/var(--dif)*100%);     width: calc((var(--b) - var(--a))/var(--dif)*100%);   } }

In order to represent the width and min-width values as percentages, we need to divide the difference between our two values by the difference (--dif) between the maximum and the minimum of the range inputs and then multiply the result we get by 100%.

See the Pen by thebabydino (@thebabydino) on CodePen.

So far, so good… so what?

The ::after always has the right computed width, but we also need to offset it from the track minimum by the smaller value and we can’t use the same trick for its margin-left property.

My first instinct here was to use left, but actual offsets don’t work on their own. We’d have to also explicitly set position: relative on our ::after pseudo-element in order to make it work. I felt kind of meh about doing that, so I opted for margin-left instead.

The question is what approach can we take for this second property. The one we’ve used for the width doesn’t work because there is no such thing as min-margin-left.

A min() function is now in the CSS spec, but at the time when I coded these multi-thumb sliders, it was only implemented by Safari (it has since landed in Chrome as well). Safari-only support was not going to cut it for me since I don’t own any Apple device or know anyone in real life who does… so I couldn’t play with this function! And not being able to come up with a solution I could actually test meant having to change the approach.

Second approach

This involves using both of our wrapper’s (.wrap) pseudo-elements: one pseudo-element’s margin-left and width being set as if the second value is bigger, and the other’s set as if the first value is bigger.

With this technique, if the second value is bigger, the width we’re setting on ::before is positive and the one we’re setting on ::after is negative (which means it’s invalid and the default of 0 is applied, hiding this pseudo-element). Meanwhile, if the first value is bigger, then the width we’re setting on ::before is negative (so it’s this pseudo-element that has a computed width of 0 and is not being shown in this situation) and the one we’re setting on ::after is positive.

Similarly, we use the first value (--a) to set the margin-left property on the ::before since we assume the second value --b is bigger for this pseudo-element. That means --a is the value of the left end and --b the value of the right end.

For ::after, we use the second value (--b) to set the margin-left property, since we assume the first value --a is bigger this pseudo-element. That means --b is the value of the left end and --a the value of the right end.

Let’s see how we put it into code for the same two examples we previously had, where one has --b bigger and another where --a is bigger:

<div style='--a: 30%; --b: 50%'></div> <div style='--a: 60%; --b: 10%'></div>
div {   &::before, &::after {     content: '';     height: 5em;   }      &::before {     margin-left: var(--a);     width: calc(var(--b) - var(--a));   }    &::after {     margin-left: var(--b);     width: calc(var(--a) - var(--b));   } }

See the Pen by thebabydino (@thebabydino) on CodePen.

Applying this technique for our two thumb slider, we have:

.wrap {   /* same as before */   --dif: calc(var(--max) - var(--min));      &::before, &::after {     grid-column: 1/ span 2;     grid-row: 3;     height: 100%;     background: #95a;     content: ''   }      &::before {     margin-left: calc((var(--a) - var(--min))/var(--dif)*100%);     width: calc((var(--b) - var(--a))/var(--dif)*100%)   }      &::after {     margin-left: calc((var(--b) - var(--min))/var(--dif)*100%);     width: calc((var(--a) - var(--b))/var(--dif)*100%)   } }

See the Pen by thebabydino (@thebabydino) on CodePen.

We now have a nice functional slider with two thumbs. But this solution is far from perfect.

Issues

The first issue is that we didn’t get those margin-left and width values quite right. It’s just not noticeable in this demo due to the thumb styling (such as its shape, dimensions relative to the track, and being full opaque).

But let’s say our thumb is round and maybe even smaller than the track height:

See the Pen by thebabydino (@thebabydino) on CodePen.

We can now see what the problem is: the endlines of the fill don’t coincide with the vertical midlines of the thumbs.

This is because of the way moving the thumb end-to-end works. In Chrome, the thumb’s border-box moves within the limits of the track’s content-box, while in Firefox, it moves within the limits of the slider’s content-box. This can be seen in the recordings below, where the padding is transparent, while the content-box and the border are semi-transparent. We’ve used orange for the actual slider, red for the track and purple for the thumb.

Animated gif. Chrome only moves the thumb within the left and right limits of the track's content-box.
Recording of the thumb motion in Chrome from one end of the slider to the other.

Note that the track’s width in Chrome is always determined by that of the parent slider – any width value we may set on the track itself gets ignored. This is not the case in Firefox, where the track can also be wider or narrower than its parent <input>. As we can see below, this makes it even more clear that the thumb’s range of motion depends solely on the slider width in this browser.

Animated gif. Firefox moves the thumb within the left and right limits of the actual range input's content-box.
Recording of the thumb motion in Firefox from one end of the slider to the other. The three cases are displayed from top to bottom. The border-box of the track perfectly fits the content-box of the slider horizontally. It’s longer and it’s shorter).

In our particular case (and, to be fair, in a lot of other cases), we can get away with not having any margin, border or padding on the track. That would mean its content-box coincides to that of the actual range input so there are no inconsistencies between browsers.

But what we need to keep in mind is that the vertical midlines of the thumbs (which we need to coincide with the fill endpoints) move between half a thumb width (or a thumb radius if we have a circular thumb) away from the start of the track and half a thumb width away from the end of the track. That’s an interval equal to the track width minus the thumb width (or the thumb diameter in the case of a circular thumb).

This can be seen in the interactive demo below where the thumb can be dragged to better see the interval its vertical midline (which we need to coincide with the fill’s endline) moves within.

See the Pen by thebabydino (@thebabydino) on CodePen.

The demo is best viewed in Chrome and Firefox.

The fill width and margin-left values are not relative to 100% (or the track width), but to the track width minus the thumb width (which is also the diameter in the particular case of a circular thumb). Also, the margin-left values don’t start from 0, but from half a thumb width (which is a thumb radius in our particular case).

$ d: .5*$ h; // thumb diameter $ r: .5*$ d; // thumb radius $ uw: $ w - $ d; // useful width  .wrap {   /* same as before */   --dif: calc(var(--max) - var(--min)); 	   &::before {     margin-left: calc(#{$ r} + (var(--a) - var(--min))/var(--dif)*#{$ uw});     width: calc((var(--b) - var(--a))/var(--dif)*#{$ uw});   }      &::after {     margin-left: calc(#{$ r} + (var(--b) - var(--min))/var(--dif)*#{$ uw});     width: calc((var(--a) - var(--b))/var(--dif)*#{$ uw});   } }

Now the fill starts and ends exactly where it should, along the midlines of the two thumbs:

See the Pen by thebabydino (@thebabydino) on CodePen.

This one issue has been taken care of, but we still have a way bigger one. Let’s say we want to have more thumbs, say four:

Animated gif. Shows a slider with four thumbs which can pass each other and be in any order, while the fills are always between the two thumbs with the two smallest values and between the two thumbs with the two biggest values, regardless of their order in the DOM.
An example with four thumbs.

We now have four thumbs that can all pass each other and they can be in any order that we have no way of knowing. Moreover, we only have two pseudo-elements, so we cannot apply the same techniques. Can we still find a CSS-only solution?

Well, the answer is yes! But it means scrapping this solution and going for something different and way more clever — in part two of this article!

Article Series:

  1. Multi-Thumb Sliders: Particular Two-Thumb Case (This Post)
  2. Multi-Thumb Sliders: General Case (Coming Tomorrow!)

The post Multi-Thumb Sliders: Particular Two-Thumb Case appeared first on CSS-Tricks.

CSS-Tricks

, , , ,
[Top]