Let’s check those steps one by one more thoroughly.
1. Mouse & Touch Events
To get the mouse or touch position, we first need to add event listeners on our SVG. We can use the Pointer Events to handle all kind of pointers (mouse/touch/stylus/…) but those events are not yet supported by all browsers. We will need to add some fallback to make sure all users will be able to drag the SVG.
// We select the SVG into the page
var svg = document.querySelector('svg');
// If browser supports pointer events
if (window.PointerEvent) {
svg.addEventListener('pointerdown', onPointerDown); // Pointer is pressed
svg.addEventListener('pointerup', onPointerUp); // Releasing the pointer
svg.addEventListener('pointerleave', onPointerUp); // Pointer gets out of the SVG area
svg.addEventListener('pointermove', onPointerMove); // Pointer is moving
} else {
// Add all mouse events listeners fallback
svg.addEventListener('mousedown', onPointerDown); // Pressing the mouse
svg.addEventListener('mouseup', onPointerUp); // Releasing the mouse
svg.addEventListener('mouseleave', onPointerUp); // Mouse gets out of the SVG area
svg.addEventListener('mousemove', onPointerMove); // Mouse is moving
// Add all touch events listeners fallback
svg.addEventListener('touchstart', onPointerDown); // Finger is touching the screen
svg.addEventListener('touchend', onPointerUp); // Finger is no longer touching the screen
svg.addEventListener('touchmove', onPointerMove); // Finger is moving
}
Because we could have touch events and pointer events, we need to create a tiny function to returns to coordinates either from the first finger either from a pointer.
// This function returns an object with X & Y values from the pointer event
function getPointFromEvent (event) {
var point = {x:0, y:0};
// If event is triggered by a touch event, we get the position of the first finger
if (event.targetTouches) {
point.x = event.targetTouches[0].clientX;
point.y = event.targetTouches[0].clientY;
} else {
point.x = event.clientX;
point.y = event.clientY;
}
return point;
}
Once the page is ready and waiting for any user interactions, we can start handling the mousedown/touchstart events to save the original coordinates of the pointer and create a variable to let us know if the pointer is down or not.
// This variable will be used later for move events to check if pointer is down or not
var isPointerDown = false;
// This variable will contain the original coordinates when the user start pressing the mouse or touching the screen
var pointerOrigin = {
x: 0,
y: 0
};
// Function called by the event listeners when user start pressing/touching
function onPointerDown(event) {
isPointerDown = true; // We set the pointer as down
// We get the pointer position on click/touchdown so we can get the value once the user starts to drag
var pointerPosition = getPointFromEvent(event);
pointerOrigin.x = pointerPosition.x;
pointerOrigin.y = pointerPosition.y;
}
2. Calculate Mouse Offsets
Now that we have the coordinates of the original position where the user started to drag inside the SVG, we can calculate the distance between the current pointer position and its origin. We do this for both the X and Y axis and we apply the calculated values on the viewBox.
// We save the original values from the viewBox
var viewBox = {
x: 0,
y: 0,
width: 500,
height: 500
};
// The distances calculated from the pointer will be stored here
var newViewBox = {
x: 0,
y: 0
};
// Function called by the event listeners when user start moving/dragging
function onPointerMove (event) {
// Only run this function if the pointer is down
if (!isPointerDown) {
return;
}
// This prevent user to do a selection on the page
event.preventDefault();
// Get the pointer position
var pointerPosition = getPointFromEvent(event);
// We calculate the distance between the pointer origin and the current position
// The viewBox x & y values must be calculated from the original values and the distances
newViewBox.x = viewBox.x - (pointerPosition.x - pointerOrigin.x);
newViewBox.y = viewBox.y - (pointerPosition.y - pointerOrigin.y);
// We create a string with the new viewBox values
// The X & Y values are equal to the current viewBox minus the calculated distances
var viewBoxString = `${newViewBox.x} ${newViewBox.y} ${viewBox.width} ${viewBox.height}`;
// We apply the new viewBox values onto the SVG
svg.setAttribute('viewBox', viewBoxString);
document.querySelector('.viewbox').innerHTML = viewBoxString;
}
If you don’t feel comfortable with the concept of viewBox, I would suggest you first read this great article by Sara Soueidan.
3. Save Updated viewBox
Now that the viewBox has been updated, we need to save its new values when the user stops dragging the SVG.
This step is important because otherwise we would always calculate the pointer offsets from the original viewBox values and the user will drag the SVG from the starting point every time.
function onPointerUp() {
// The pointer is no longer considered as down
isPointerDown = false;
// We save the viewBox coordinates based on the last pointer offsets
viewBox.x = newViewBox.x;
viewBox.y = newViewBox.y;
}
4. Handle Dynamic Viewport
If we set a custom width on our SVG, you may notice while dragging on the demo below that the bird is moving either faster or slower than your pointer.
On the original demo, the SVG’s width is exactly matching its viewBox width. The actual size of your SVG may also be called viewport. In a perfect situation, when the user is moving their pointer by 1px, we want the viewBox to translate by 1px.
But, most of the time, the SVG has a responsive size and the viewBox will most likely not match the SVG viewport. If the SVG’s width is twice as big than the viewBox, when the user moves their pointer by 1px, the image inside the SVG will translate by 2px.
To fix this, we need to calculate the ratio between the viewBox and the viewport and apply this ratio while calculating the new viewBox. This ratio must also be updated whenever the SVG size may change.
// Calculate the ratio based on the viewBox width and the SVG width
var ratio = viewBox.width / svg.getBoundingClientRect().width;
window.addEventListener('resize', function() {
ratio = viewBox.width / svg.getBoundingClientRect().width;
});
Once we know the ratio, we need to multiply the mouse offsets by the ratio to proportionally increase or reduce the offsets.
To make our code a bit shorter, there are two very useful concepts in SVG we could use.
SVG Points
The first concept is to use SVG Points instead of basic Javascript objects to save the pointer’s positions. After creating a new SVG Point variable, we can apply some Matrix Transformation on it to convert the position relative to the screen to a position relative to the current SVG user units.
Check the code below to see how the functions getPointFromEvent() and onPointerDown() have changed.
// Create an SVG point that contains x & y values
var point = svg.createSVGPoint();
function getPointFromEvent (event) {
if (event.targetTouches) {
point.x = event.targetTouches[0].clientX;
point.y = event.targetTouches[0].clientY;
} else {
point.x = event.clientX;
point.y = event.clientY;
}
// We get the current transformation matrix of the SVG and we inverse it
var invertedSVGMatrix = svg.getScreenCTM().inverse();
return point.matrixTransform(invertedSVGMatrix);
}
var pointerOrigin;
function onPointerDown(event) {
isPointerDown = true; // We set the pointer as down
// We get the pointer position on click/touchdown so we can get the value once the user starts to drag
pointerOrigin = getPointFromEvent(event);
}
By using SVG Points, you don’t even have to handle transformations applied on your SVG! Compare the following two examples where the first is broken when a rotation is applied on the SVG and the second example uses SVG Points.
The second unknown concept in SVG we can use to shorten our code, is the usage of Animated Rect.
Because the viewBox is actually considered as an SVG Rectangle (x, y, width, height), we can create a variable from its base value that will automatically update the viewBox if we update this variable.
See how easier it is now to update the viewBox of our SVG!
// We save the original values from the viewBox
var viewBox = svg.viewBox.baseVal;
function onPointerMove (event) {
if (!isPointerDown) {
return;
}
event.preventDefault();
// Get the pointer position as an SVG Point
var pointerPosition = getPointFromEvent(event);
// Update the viewBox variable with the distance from origin and current position
// We don't need to take care of a ratio because this is handled in the getPointFromEvent function
viewBox.x -= (pointerPosition.x - pointerOrigin.x);
viewBox.y -= (pointerPosition.y - pointerOrigin.y);
}
And here is the final demo. See how much shorter the code is now? 😀
This solution is definitely not the only way to go to handle such behavior. If you are already using a library to deal with your SVGs, it may already have a built-in function to handle it.
I hope this article may help you to understand a bit more how powerful SVG can be! Feel free to contribute to the code by commenting with your ideas or alternatives to this solution.
Y’all know about font-display? It’s pretty great. It’s a CSS property that you can use within @font-face blocks to control how, visually, that font loads. Font loading is really pretty damn complicated. Here’s a guide from Zach Leatherman to prove it, which includes over 10 font loading strategies, including strategies that involve critical inline CSS of subsets of fonts combined with loading the rest of the fonts later through JavaScript. It ain’t no walk in the park.
Using font-displayis kinda like a walk in the park though. It’s just a single line of CSS. It doesn’t solve everything that Zach’s more exotic demos do, but it can go a long way with that one line. It’s notable to bring up right now, as support has improved a lot lately. It’s now in Firefox 58+, Chrome 60+, Safari 11.1+, iOS 11.3+, and Chrome on Android 64+. Pretty good.
What do you get from it? The ability to control FOUT and FOIT as is right for your project, two things that both kinda suck in regards to font loading. We’ve got a couple posts on it around here:
FOUT = Flash of Unstyled Text
FOIT = Flash of Invisible Text
Neither is great. In a perfect world, our custom fonts just show up immediately. But since that’s not a practical possibility, we pick based on our priorities.
If you’re OK with FOUT, you’re probably best off with font-display: swap; which will display a fallback font fairly fast, but swap in your custom font when it loads.
If you’re OK with FOIT, you’re probably best off with font-display: block; which is fairly similar to current browser behavior, where it shows nothing as it waits for the custom font, but will eventually fall back.
If you only want the custom font to show at all if it’s there immediately,font-display: optional; is what you want. It’ll still load in the background and be there next page load probably.
Those are some pretty decent options for a single line of CSS. But again, remember if you’re running a major text-heavy site with custom fonts, Zach’s guide can help you do more.
I’d almost go out on a limb and say: every @font-face block out there should have a font-display property. With the only caveat being you’re doing something exotic and for some reason want the browser default behavior.
Wanna hear something quite unfortunate? We already mentioned font-display: block;. Wouldn’t you think it, uh, well, blocked the rendering of text until the custom font loads? It doesn’t. It’s still got a swap period. It would be the perfect thing for something like icon fonts where the icon (probably) has no meaning unless the custom font loads. Alas, there is no font-display solution for that.
I used to think implementing swipe gestures had to be very difficult, but I have recently found myself in a situation where I had to do it and discovered the reality is nowhere near as gloomy as I had imagined.
This article is going to take you, step by step, through the implementation with the least amount of code I could come up with. So, let’s jump right into it!
The HTML Structure
We start off with a .container that has a bunch of images inside:
We use display: flex to make sure images go alongside each other with no spaces in between. align-items: center middle aligns them vertically. We make both the images and the container take the width of the container’s parent (the body in our case).
.container {
display: flex;
align-items: center;
width: 100%;
img {
min-width: 100%; /* needed so Firefox doesn't make img shrink to fit */
width: 100%; /* can't take this out either as it breaks Chrome */
}
}
The fact that both the .container and its child images have the same width makes these images spill out on the right side (as highlighted by the red outline) creating a horizontal scrollbar, but this is precisely what we want:
Given that not all the images have the same dimensions and aspect ratio, we have a bit of white space above and below some of them. So, we’re going to trim that by giving the .container an explicit height that should pretty much work for the average aspect ratio of these images and setting overflow-y to hidden:
.container {
/* same as before */
overflow-y: hidden;
height: 50vw;
max-height: 100vh;
}
The result can be seen below, with all the images trimmed to the same height and no empty spaces anymore:
The result after images are trimmed by overflow-y on the .container (see live demo).
Alright, but now we have a horizontal scrollbar on the .container itself. Well, that’s actually a good thing for the no JavaScript case.
Otherwise, we create a CSS variable --n for the number of images and we use this to make .container wide enough to hold all its image children that still have the same width as its parent (the body in this case):
Note that we keep the previous width declarations as fallbacks. The calc() values won’t change a thing until we set --n from the JavaScript after getting our .container and the number of child images it holds:
const _C = document.querySelector('.container'),
N = _C.children.length;
_C.style.setProperty('--n', N)
Now our .container has expanded to fit all the images inside:
Next, we get rid of the horizontal scrollbar by setting overflow-x: hidden on our container’s parent (the body in our case) and we create another CSS variable that holds the index of the currently selected image (--i). We use this to properly position the .container with respect to the viewport via a translation (remember that % values inside translate() functions are relative to the dimensions of the element we have set this transform on):
body { overflow-x: hidden }
.container {
/* same styles as before */
transform: translate(calc(var(--i, 0)/var(--n)*-100%));
}
Changing the --i to a different integer value greater or equal to zero, but smaller than --n, brings another image into view, as illustrated by the interactive demo below (where the value of --i is controlled by a range input):
Alright, but we don’t want to use a slider to do this.
The basic idea is that we’re going to detect the direction of the motion between the "touchstart" (or "mousedown") event and the "touchend" (or "mouseup") and then update --i accordingly to move the container such that the next image (if there is one) in the desired direction moves into the viewport.
function lock(e) {};
function move(e) {};
_C.addEventListener('mousedown', lock, false);
_C.addEventListener('touchstart', lock, false);
_C.addEventListener('mouseup', move, false);
_C.addEventListener('touchend', move, false);
Note that this will only work for the mouse if we set pointer-events: none on the images.
.container {
/* same styles as before */
img {
/* same styles as before */
pointer-events: none;
}
}
Also, Edge needs to have touch events enabled from about:flags as this option is off by default:
Enabling touch events in Edge.
Before we populate the lock() and move() functions, we unify the touch and click cases:
function unify(e) { return e.changedTouches ? e.changedTouches[0] : e };
Locking on "touchstart" (or "mousedown") means getting and storing the x coordinate into an initial coordinate variable x0:
let x0 = null;
function lock(e) { x0 = unify(e).clientX };
In order to see how to move our .container (or if we even do that because we don’t want to move further when we have reached the end), we check if we have performed the lock() action, and if we have, we read the current x coordinate, compute the difference between it and x0 and resolve what to do out of its sign and the current index:
let i = 0;
function move(e) {
if(x0 || x0 === 0) {
let dx = unify(e).clientX - x0, s = Math.sign(dx);
if((i > 0 || s < 0) && (i < N - 1 || s > 0))
_C.style.setProperty('--i', i -= s);
x0 = null
}
};
The result on dragging left/ right can be seen below:
Switching between images on swipe (live demo). Attempts to move to the right on the first image or left on the last one do nothing as we have no other image before or after, respectively.
The above is the expected result and the result we get in Chrome for a little bit of drag and Firefox. However, Edge navigates backward and forward when we drag left or right, which is something that Chrome also does on a bit more drag.
Edge navigating the pageview backward or forward on left or right swipe.
In order to override this, we need to add a "touchmove" event listener:
_C.addEventListener('touchmove', e => {e.preventDefault()}, false)
Sadly, there’s an Edge bug that makes any transition to a CSS variable-depending calc() translation fail. Ugh, I guess we have to forget about Edge for now.
Refining the Whole Thing
With all the cool swipe effects out there, what we have so far doesn’t quite cut it, so let’s see what improvements can be made.
Better Visual Cues While Dragging
First off, nothing happens while we drag, all the action follows the "touchend" (or "mouseup") event. So, while we drag, we have no indication of what’s going to happen next. Is there a next image to switch to in the desired direction? Or have we reached the end of the line and nothing will happen?
To take care of that, we tweak the translation amount a bit by adding a CSS variable --tx that’s originally 0px:
We use two more event listeners: one for "touchmove" and another for "mousemove". Note that we were already preventing backward and forward navigation in Chrome using the "touchmove" listener:
Now let’s populate the drag() function! If we have performed the lock() action, we read the current x coordinate, compute the difference dx between this coordinate and the initial one x0 and set --tx to this value (which is a pixel value).
We also need to make sure to reset --tx to 0px at the end and remove the transition for the duration of the drag. In order to make this easier, we move the transition declaration on a .smooth class:
.smooth { transition: transform .5s ease-out; }
In the lock() function, we remove this class from the .container (we’ll add it again at the end on "touchend" and "mouseup") and also set a locked boolean variable, so we don’t have to keep performing the x0 || x0 === 0 check. We then use the locked variable for the checks instead:
let locked = false;
function lock(e) {
x0 = unify(e).clientX;
_C.classList.toggle('smooth', !(locked = true))
};
function drag(e) {
e.preventDefault();
if(locked) { /* same as before */ }
};
function move(e) {
if(locked) {
let dx = unify(e).clientX - x0, s = Math.sign(dx);
if((i > 0 || s < 0) && (i < N - 1 || s > 0))
_C.style.setProperty('--i', i -= s);
_C.style.setProperty('--tx', '0px');
_C.classList.toggle('smooth', !(locked = false));
x0 = null
}
};
The result can be seen below. While we’re still dragging, we now have a visual indication of what’s going to happen next:
Swipe with visual cues while dragging (live demo).
Fix the transition-duration
At this point, we’re always using the same transition-duration no matter how much of an image’s width we still have to translate after the drag. We can fix that in a pretty straightforward manner by introducing a factor f, which we also set as a CSS variable to help us compute the actual animation duration:
Let’s say that we don’t want to move on to the next image if we only drag a little bit below a certain threshold. Because now, a 1px difference during the drag means we advance to the next image and that feels a bit unnatural.
To fix this, we set a threshold at let’s say 20% of an image’s width:
function move(e) {
if(locked) {
let dx = unify(e).clientX - x0, s = Math.sign(dx),
f = +(s*dx/w).toFixed(2);
if((i > 0 || s < 0) && (i < N - 1 || s > 0) && f > .2) {
/* same as before */
}
/* same as before */
}
};
The result can be seen below:
We only advance to the next image if we drag enough (live demo).
Maybe Add a Bounce?
This is something that I’m not sure was a good idea, but I was itching to try anyway: change the timing function so that we introduce a bounce. After a bit of dragging the handles on cubic-bezier.com, I came up with a result that seemed promising:
What our chosen cubic Bézier timing function looks like compared to a plain ease-out.
Using a custom CSS timing function to introduce a bounce (live demo).
How About the JavaScript Way, Then?
We could achieve a better degree of control over more natural-feeling and more complex bounces by taking the JavaScript route for the transition. This would also give us Edge support.
We start by getting rid of the transition and the --tx and --f CSS variables. This reduces our transform to what it was initially:
The above code also means --i won’t necessarily be an integer anymore. While it remains an integer while we have a single image fully into view, that’s not the case anymore while we drag or during the motion after triggering the "touchend" or "mouseup" events.
For example, while we have the first image fully in view, --i is 0. While we have the second one fully in view, --i is 1. When we’re midway between the first and the second, --i is .5. When we have a quarter of the first one and three quarters of the second one in view, --i is .75.
We then update the JavaScript to replace the code parts where we were updating these CSS variables. First, we take care of the lock() function, where we ditch toggling the .smooth class and of the drag() function, where we replace updating the --tx variable we’ve ditched with updating --i, which, as mentioned before, doesn’t need to be an integer anymore:
function lock(e) {
x0 = unify(e).clientX;
locked = true
};
function drag(e) {
e.preventDefault();
if(locked) {
let dx = unify(e).clientX - x0,
f = +(dx/w).toFixed(2);
_C.style.setProperty('--i', i - f)
}
};
Before we also update the move() function, we introduce two new variables, ini and fin. These represent the initial value we set --i to at the beginning of the animation and the final value we set the same variable to at the end of the animation. We also create an animation function ani():
let ini, fin;
function ani() {};
function move(e) {
if(locked) {
let dx = unify(e).clientX - x0,
s = Math.sign(dx),
f = +(s*dx/w).toFixed(2);
ini = i - s*f;
if((i > 0 || s < 0) && (i < N - 1 || s > 0) && f > .2) {
i -= s;
f = 1 - f
}
fin = i;
ani();
x0 = null;
locked = false;
}
};
This is not too different from the code we had before. What has changed is that we’re not setting any CSS variables in this function anymore but instead set the ini and the fin JavaScript variables and call the animation ani() function.
ini is the initial value we set --i to at the beginning of the animation that the "touchend"/ "mouseup" event triggers. This is given by the current position we have when one of these two events fires.
fin is the final value we set --i to at the end of the same animation. This is always an integer value because we always end with one image fully into sight, so fin and --i are the index of that image. This is the next image in the desired direction if we dragged enough (f > .2) and if there is a next image in the desired direction ((i > 0 || s < 0) && (i < N - 1 || s > 0)). In this case, we also update the JavaScript variable storing the current image index (i) and the relative distance to it (f). Otherwise, it’s the same image, so i and f don’t need to get updated.
Now, let’s move on to the ani() function. We start with a simplified linear version that leaves out a change of direction.
const NF = 30;
let rID = null;
function stopAni() {
cancelAnimationFrame(rID);
rID = null
};
function ani(cf = 0) {
_C.style.setProperty('--i', ini + (fin - ini)*cf/NF);
if(cf === NF) {
stopAni();
return
}
rID = requestAnimationFrame(ani.bind(this, ++cf))
};
The main idea here is that the transition between the initial value ini and the final one fin happens over a total number of frames NF. Every time we call the ani() function, we compute the progress as the ratio between the current frame index cf and the total number of frames NF. This is always a number between 0 and 1 (or you can take it as a percentage, going from 0% to 100%). We then use this progress value to get the current value of --i and set it in the style attribute of our container _C. If we got to the final state (the current frame index cf equals the total number of frames NF, we exit the animation loop). Otherwise, we just increment the current frame index cf and call ani() again.
At this point, we have a working demo with a linear JavaScript transition:
Version with linear JavaScript transition (live demo).
However, this has the problem we initially had in the CSS case: no matter the distance, we have to have to smoothly translate our element over on release ("touchend" / "mouseup") and the duration is always the same because we always animate over the same number of frames NF.
Let’s fix that!
In order to do so, we introduce another variable anf where we store the actual number of frames we use and whose value we compute in the move() function, before calling the animation function ani():
function move(e) {
if(locked) {
let dx = unify(e).clientX - x0,
s = Math.sign(dx),
f = +(s*dx/w).toFixed(2);
/* same as before */
anf = Math.round(f*NF);
ani();
/* same as before */
}
};
We also need to replace NF with anf in the animation function ani():
function ani(cf = 0) {
_C.style.setProperty('--i', ini + (fin - ini)*cf/anf);
if(cf === anf) { /* same as before */ }
/* same as before */
};
With this, we have fixed the timing issue!
Version with linear JavaScript transition at constant speed (live demo).
Alright, but a linear timing function isn’t too exciting.
We could try the JavaScript equivalents of CSS timing functions such as ease-in, ease-out or ease-in-out and see how they compare. I’ve already explained in a lot of detail how to get these in the previously linked article, so I’m not going to go through that again and just drop the object with all of them into the code:
The k value is the progress, which is the ratio between the current frame index cf and the actual number of frames the transition happens over anf. This means we modify the ani() function a bit if we want to use the ease-out option for example:
function ani(cf = 0) {
_C.style.setProperty('--i', ini + (fin - ini)*TFN['ease-out'](cf/anf));
/* same as before */
};
Version with ease-out JavaScript transition (live demo).
We could also make things more interesting by using the kind of bouncing timing function that CSS cannot give us. For example, something like the one illustrated by the demo below (click to trigger a transition):
The graphic for this would be somewhat similar to that of the easeOutBounce timing function from easings.net.
Graphical representation of the timing function.
The process for getting this kind of timing function is similar to that for getting the JavaScript version of the CSS ease-in-out (again, described in the previously linked article on emulating CSS timing functions with JavaScript).
We start with the cosine function on the [0, 90°] interval (or [0, π/2] in radians) for no bounce, [0, 270°] ([0, 3·π/2]) for 1 bounce, [0, 450°] ([0, 5·π/2]) for 2 bounces and so on… in general it’s the [0, (n + ½)·180°] interval ([0, (n + ½)·π]) for n bounces.
The input of this cos(k) function is in the [0, 450°] interval, while its output is in the [-1, 1] interval. But what we want is a function whose domain is the [0, 1] interval and whose codomain is also the [0, 1] interval.
We can restrict the codomain to the [0, 1] interval by only taking the absolute value |cos(k)|:
While we got the interval we wanted for the codomain, we want the value of this function at 0 to be 0 and its value at the other end of the interval to be 1. Currently, it’s the other way around, but we can fix this if we change our function to 1 - |cos(k)|:
Now we can move on to restricting the domain from the [0, (n + ½)·180°] interval to the [0, 1] interval. In order to do this, we change our function to be 1 - |cos(k·(n + ½)·180°)|:
This gives us both the desired domain and codomain, but we still have some problems.
First of all, all our bounces have the same height, but we want their height to decrease as k increases from 0 to 1. Our fix in this case is to multiply the cosine with 1 - k (or with a power of 1 - k for a non-linear decrease in amplitude). The interactive demo below shows how this amplitude changes for various exponents a and how this influences the function we have so far:
Secondly, all the bounces take the same amount of time, even though their amplitudes keep decreasing. The first idea here is to use a power of k inside the cosine function instead of just k. This manages to make things weird as the cosine doesn’t hit 0 at equal intervals anymore, meaning we don’t always get that f(1) = 1 anymore which is what we’d always need from a timing function we’re actually going to use. However, for something like a = 2.75, n = 3 and b = 1.5, we get a result that looks satisfying, so we’ll leave it at that, even though it could be tweaked for better control:
The timing function we want to try.
This is the function we try out in the JavaScript if we want some bouncing to happen.
const TFN = {
/* the other function we had before */
'bounce-out': function(k, n = 3, a = 2.75, b = 1.5) {
return 1 - Math.pow(1 - k, a)*Math.abs(Math.cos(Math.pow(k, b)*(n + .5)*Math.PI))
}
};
Hmm, seems a bit too extreme in practice:
Version with a bouncing JavaScript transition (live demo).
Maybe we could make n depend on the amount of translation we still need to perform from the moment of the release. We make it into a variable which we then set in the move() function before calling the animation function ani():
const TFN = {
/* the other function we had before */
'bounce-out': function(k, a = 2.75, b = 1.5) {
return 1 - Math.pow(1 - k, a)*Math.abs(Math.cos(Math.pow(k, b)*(n + .5)*Math.PI))
}
};
var n;
function move(e) {
if(locked) {
let dx = unify(e).clientX - x0,
s = Math.sign(dx),
f = +(s*dx/w).toFixed(2);
/* same as before */
n = 2 + Math.round(f)
ani();
/* same as before */
}
};
This gives us our final result:
Version with the final bouncing JavaScript transition (live demo).
There’s definitely still room for improvement, but I don’t have a feel for what makes a good animation, so I’ll just leave it at that. As it is, this is now functional cross-browser (without have any of the Edge issues that the version using a CSS transition has) and pretty flexible.
List rendering is one of the most commonly used practices in front-end web development. Dynamic list rendering is often used to present a series of similarly grouped information in a concise and friendly format to the user. In almost every web application we use, we can see lists of content in numerous areas of the app.
In this article we’ll gather an understanding of Vue’s v-for directive in generating dynamic lists, as well as go through some examples of why the key attribute should be used when doing so.
Since we’ll be explaining things thoroughly as we start to write code, this article assumes you’ll have no or very little knowledge with Vue (and/or other JavaScript frameworks).
Case Study: Twitter
We’re going to use Twitter as the case study for this article.
When logged in and in the main index route of Twitter we’re presented with a view similar to this:
On the homepage, we’ve become accustomed to seeing a list of trends, a list of tweets, a list of potential followers, etc. The content displayed in these lists depends on a multitude of factors—our Twitter history, who we follow, our likes, etc. As a result, we can say all this data is dynamic.
Though this data is dynamically obtained, the way this data is shown remains the same. This is in part due to using reusable web components.
For example; we can see the list of tweets as a list of single tweet-component items. We can think of tweet-component as a shell that takes data of sorts, such as the username, handle, tweet and avatar, among other pieces, and that simply displays those pieces in a consistent markup.
Let’s say we wanted to render a list of components (e.g. a list of tweet-component items) based on a large data source obtained from a server. In Vue, the first thing that should come to mind to accomplish this is the v-for directive.
The v-for directive
The v-for directive is used to render a list of items based on a data source. The directive can be used on a template element and requires a specific syntax along the lines of:
Let’s see an example of this in practice. First, we’ll assume we’ve already obtained a collection of tweet data:
const tweets = [
{
id: 1,
name: 'James',
handle: '@jokerjames',
img: 'https://semantic-ui.com/images/avatar2/large/matthew.png',
tweet: "If you don't succeed, dust yourself off and try again.",
likes: 10,
},
{
id: 2,
name: 'Fatima',
handle: '@fantasticfatima',
img: 'https://semantic-ui.com/images/avatar2/large/molly.png',
tweet: 'Better late than never but never late is better.',
likes: 12,
},
{
id: 3,
name: 'Xin',
handle: '@xeroxin',
img: 'https://semantic-ui.com/images/avatar2/large/elyse.png',
tweet: 'Beauty in the struggle, ugliness in the success.',
likes: 18,
}
]
tweets is a collection of tweet objects with each tweet containing details of that particular tweet—a unique identifier, the name/handle of the account, tweet message, etc. Let’s now attempt to use the v-for directive to render a list of tweet components based on this data.
First and foremost, we’ll create the Vue instance—the heart of the Vue application. We’ll mount/attach our instance to a DOM element of id app and assign the tweets collection as part of the instance’s data object.
new Vue({
el: '#app',
data: {
tweets
}
});
We’ll now go ahead and create a tweet-component that our v-for directive will use to render a list. We’ll use the global Vue.component constructor to create a component named tweet-component:
The tweet-component expects a tweet object prop as seen in the prop validation requirement (props: {tweet: Object}). If the component is rendered with a tweet prop that is not an object, Vue will emit warnings.
We’re binding the properties of the tweet object prop on to the component template with the help of the Mustache syntax: {{ }}.
The component markup adapts Bulma’s Box element as it represents a good resemblance to a tweet.
In the HTML template, we’ll need to create the markup where our Vue app will be mounted (i.e. the element with the id of app). Within this markup, we’ll use the v-for directive to render a list of tweets. Since tweets is the data collection we’ll be iterating over, tweet will be an appropriate alias to use in the directive. In each rendered tweet-component, we’ll also pass in the iterated tweet object as props for it to be accessed in the component.
Regardless of how many more tweet objects would be introduced to the collection; or how they’ll change over time—our set up will always render all the tweets in the collection in the same markup we expect.
With the help of some custom CSS, our app will look something like this:
Though everything works as expected, we may be prompted with a Vue tip in our browser console:
[Vue tip]: <tweet-component v-for="tweet in tweets">: component lists rendered with v-for should have explicit keys...
You may not be able to see the warning in the browser console when running the code through CodePen.
Why is Vue telling us to specify explicit keys in our list when everything works as expected?
key
It’s common practice to specify a key attribute for every iterated element within a rendered v-for list. This is because Vue uses the key attribute to create unique bindings for each node’s identity.
Let’s explain this some more—if there were any dynamic UI changes to our list (e.g. order of list items gets shuffled), Vue will opt towards changing data within each element instead of moving the DOM elements accordingly. This won’t be an issue in most cases. However, in certain instances where our v-for list depends on DOM state and/or child component state, this can cause some unintended behavior.
Let’s see an example of this. What if our simple tweet component now contained an input field that will allow the user to directly respond to the tweet message? We’ll ignore how this response could be submitted and simply address the new input field itself:
We’ll include this new input field on to the template of tweet-component:
We’ve attached a click event listener on the button element to call a shuffle method when triggered. In our Vue instance; we’ll create the shuffle method responsible in randomly shuffling the tweets collection in the instance. We’ll use lodash’s _shuffle method to achieve this:
However, if we type some information in the input of each component then click shuffle; we’ll notice something peculiar happening:
Since we haven’t opted to using the key attribute, Vue has not created unique bindings to each tweet node. As a result, when we’re aiming to reorder the tweets, Vue takes the more performant saving approach to simply change (or patch) data in each element. Since the temporary DOM state (i.e. the inputted text) remains in place, we experience this unintended mismatch.
Here’s a diagram that shows us the data that gets patched on to each element and the DOM state that remains in place:
To avoid this; we’ll have to assign a unique key to every tweet-component rendered in the list. We’ll use the id of a tweet to be the unique identifier since we should safely say a tweet’s id shouldn’t be equal to that of another. Because we’re using dynamic values, we’ll use the v-bind directive to bind our key to the tweet.id:
Now, Vue recognizes each tweet’s node’s identity; and thus will reorder the components when we intend on shuffling the list.
Since each tweet component is now being moved accordingly, we can take this a step further and use Vue’s transition-group to show how the elements are being reordered.
To do this, we’ll add the transition-group element as a wrapper to the v-for list. We’ll specify a transition name of tweets and declare that the transition group should be rendered as a div element.
Based on the name of the transition, Vue will automatically recognize if any CSS transitions/animations have been specified. Since we aim to invoke a transition for the movement of items in the list; Vue will look for a specified CSS transition along the lines of tweets-move (where tweets is the name given to our transition group). As a result, we’ll manually introduce a .tweets-move class that has a specified type and time of transition:
#app .tweets-move {
transition: transform 1s;
}
This is a very brief look into applying list transitions. Be sure to check out the Vue docs for detailed information on all the different types of transitions that can be applied!
Our tweet-component elements will now transition appropriately between locations when a shuffle is invoked. Give it a try! Type some information in the input fields and click “Shuffle!” a few times.
Pretty cool, right? Without the key attribute, the transition-group element can’t be used to create list transitions since the elements are patched in place instead of being reordered.
Should the key attribute always be used? It’s recommended. The Vue docs specify that the key attribute should only be omitted if:
We intentionally want the default manner of patching elements in place for performance reasons.
The DOM content is simple enough.
Conclusion
And there we have it! Hopefully this short article portrayed how useful the v-for directive is as well as provided a little more context to why the key attribute is often used. Let me know if you may have any questions/thoughts whatsoever!
If you liked my style of writing and are potentially interested in learning how to build apps with Vue.js, you may like the book Fullstack Vue: The Complete Guide to Vue.js that I helped publish! The book covers numerous facets of Vue including but not restricted to routing, simple state management, form handling, Vuex, server persistence, and testing. If you’re interested, you can get more information from our website, https://fullstack.io/vue.
Jeremy Keith has written a new book all about service workers and offline functionality that releases at the end of the month. The first chapter is posted on A List Apart. Now that the latest versions of iOS and macOS Safari support service workers, I can’t think of a better time to learn about how progressive web apps work under the hood. In fact, here’s an example of a simple offline site and a short series on making web apps work offline.
News of Jeremy’s book had me going back through his previous book, Resilient Web Design, where I half-remembered this super interesting quote from Chapter 4:
If you build something using web technologies, and someone visits with a web browser, you can’t be sure how many of the web technologies will be supported. It probably won’t be 100%. But it’s also unlikely to be 0%. Some people will visit with iOS devices. Others will visit with Android devices. Some people will get 80% or 90% of what you’ve designed. Others will get just 20%, 30%, or 50%. The web isn’t a platform. It’s a continuum.
I love this idea of the web as a continuum that’s constantly improving and growing over time and so I’m sure Jeremy’s latest book will be just as fun and interesting.
I like to jog. Sometimes it’s cold out. Sometimes it’s cold out, but it looks like it isn’t. The sun is shining, the birds are chirping. Then you step outside in shorts and a t-shirt and realize you have roughly 2 minutes before exposure sets in.
I decided to solve this first world problem using a lightbulb to display a certain color based on what the temperature outside is. It works better than I expected, and that’s saying something because usually nothing works out like I want it to.
This was a fun project to build, and since it is essentially a hosted service running on a timer, it’s a perfect use case for Serverless.
Now you might be thinking, “um, wouldn’t it be easier to just check the weather?” Well, it would, but then I wouldn’t have an excuse to buy an expensive lightbulb or write an article with the word “Serverless.”
So let’s look at how you can build your own Weather Bulb. The final code is not complicated, but it does have some interesting pieces that are worth noting. By the way, did I mention that it’s Serverless?
Building the Weather Bulb
The first thing you are going to need is the bulb. You can’t have a Weather Bulb sans bulb. Say the word “bulb” out loud about 10 times and you’ll notice what a bizarre word it is. Bulb, bulb, bulb, bulb — see? Weird.
I am using the LIFX Mini Color. It’s not *too* expensive, but more importantly, it’s got an API that is wide open.
The API has two methods of authentication. The first contains the word “OAuth” and I’m already sorry that you had to read that. Don’t worry, there is an easier way that doesn’t involve OAu…. that which won’t be named.
The second way is to register an application with LIFX. You get back a key and all you have to do is pass that key with any HTTP request. That’s what I’m using for this demo.
For instance, if we wanted to change the bulb color to blue, we can just pass color: blue to the /state endpoint.
The API supports a few different color formats, including named colors (like red, blue), hex values, RBG, Kevlin, hue brightness and saturation. This is important because it factors into what proved to be the hardest part of this project: turning temperature into color.
Representing Temperature With Color
If you’ve ever watched a weather report, you’ll be familiar with the way that meteorology represents weather conditions with color on a map.
Usually, this is done to visualize precipitation. You have probably seen that ominous green strip of storms bearing down on you on a weather map while you try to figure out if you should get in the bathtub because you’re in the path of a tornado. Or maybe that’s just all of us unlucky souls here in America’s Tornado Alley.
Color is also used to represent temperature. This is precisely what I wanted to do with the bulb. The tough thing is that there doesn’t seem to be a standardized way to do this. Some maps show it as solid colors in bands. In this case, blue might represent the band from 0℉ – 32℉.
Others have it as a gradient scale which is more precise. This is what I was after for the Weather Bulb.
My first stab at solving this was just to Google “temperature color scale” and other various iterations of that search term. I got back a lot of information about Kelvin.
Kelvin is a representation of the temperature of a color. Literally. For any light source (light bulb, the sun, ect) the actual temperature of that source will affect the color of the light it emits. A fire burns a yellowish red color. The hotter that fire gets, the more it moves towards white. Hence the saying, “white hot”. So if someone ever says “red hot,” you can correct them in front of everyone because who doesn’t love a pedantic jerk?
The LIFX bulb supports Kelvin, so you might think that this would work. After all, this is the Kelvin scale….
The problem is that there is simply not enough color variation because these are not actual colors, but rather the tinge of color that a light is emitting based on it’s “temperature.” Here is the Kelvin color wheel that comes with the LIFX app.
These colors are barely distinguishable from one another on the bulb. Not exactly what I was after.
That leaves me with trying to convert the color to either Hex, RGB or some other format. This is tough because where do you begin? I spent an embarrassing amount of time adjust RGB scale values between blue for cold (0, 0, 255) and red for hot (255, 0, 0). It was about this time that it dawned on me that maybe HSL would be a better way to go here. Why? Because hue is a whole lot easier to understand.
Hue
Hue is a representation of color on a scale between 0 and 360. This is why we often see color represented on a wheel (360°). That’s a vast oversimplification, but unless you want me to start talking about wavelengths, let’s go with that definition.
The hue color wheel looks like this….
If we flatten it out, it’s easier to reason about.
We’re ready to convert temperature to color. The first thing we need to do is figure out a set temperature range. I went with 0℉ to 100℉. We can’t work with infinite temperature color combinations. Numbers go on forever, colors do not. It can only get so hot before our bulb is just bright red all the time, and that’s 100℉. The same is true for cold.
If light blue represents 0℉, I can start at about the 200 mark on the hue scale. Red will represent 100℉. You can see that red is at both extremes, so I can move either left OR right, depending on what colors I want to use to represent the temperature. It’s not the same as the colors they use in actual weather programs, but who cares? Obviously not me.
I chose to go right because there is no pink on the left and pink is my favorite color. I also felt like pink represents warm a bit better than green. Green is rain and tornadoes.
Now we can back into a hue based on temperature. Ready? Here we go.
Let’s pretend it’s a brisk 50℉ outside.
If 100℉ is the hottest we go (360) and 0℉ is the coldest (200), then we have a color scale of 160 points. To figure out where in that 160 point range we need to be, we can divide the current temperature by the upper bound of 100℉ which will give us the exact percentage we need to move in our range, or 50%. If we move 50% of the way into a 160 point range, that leaves us at 80. Since we are starting at 200, that gives us a hue of 280.
That sounds complicated, but only because word problems in math SUCK. Here’s how the code looks when it’s all said and done…
let hue = 200 + (160 * ( temperature / 100 ));
OK! We’ve got a dynamic color scale based on hue, and wouldn’t you know it, we can just pass the hue to LIFX as simply as we pass a named color.
Now we just need to find out what the current temperature is, back into a hue and do that every few minutes. Serverless, here we come!
Serverless Timer Functions
Serverless is all the rage. It’s like HTML5 used to be: it doesn’t matter what it is, it only matters that you know the word and are not afraid to use it in a blog post.
For this example, we’ll use Azure Functions because there is support for timer triggers, and we can test those timer triggers locally before we deploy using VS Code. One of the things about Serverless that irritates me to no end is when I can’t debug it locally.
Timer Triggers in Azure Functions are specified as Cron Expressions. Don’t worry, I didn’t know what that was either.
Cron Expressions allow you to get very specific with interval definition. Cron breaks things down into second, minute, hour, day, month, year. So if you wanted to run something every second of every minute of every hour of every day of every year, your expression would look like this…
* * * * * *
If you wanted to run it every day at 10:15, it would look like this…
* 15 10 * * *
If you wanted to run it every 5 minutes (which is what Azure defaults to), you specify that by saying “when minutes is divisible by 5.”
0 */5 * * * *
For the purposes of this function, we set it to 2 minutes.
I am using a 2 minute interval because that’s how often we can call the weather API for free 💰.
Getting the Forecast From DarkSky
DarkSky has a wonderful weather API that you can call up to 1,000 times per day for free. If there are 1,440 minutes in a day (and there are), that means we can call DarkSky every 1.44 minutes per day and stay in the free zone. I just rounded up to 2 minutes because temperature doesn’t change that fast.
This is what our function looks like when we call the DarkSky API. All of my tokens, keys, latitude and longitude settings are in environment variables so they aren’t hardcoded. Those are set in the local.settings.json file. I used axios for my HTTP requests because it is a magical, magical package.
const axios = require('axios');
module.exports = function (context, myTimer) {
// build up the DarkSky endpoint
let endpoint = `${process.env.DS_API}/${process.env.DS_SECRET}/${process.env.LAT},
${process.env.LNG}`;
// use axios to call DarkSky for weather
axios
.get(endpoint)
.then(response => {
let temp = Math.round(response.data.currently.temperature);
// TODO: Set the color of the LIFX bulb
})
.catch(err => {
context.log(err.message);
});
};
Now that I have the temperature, I need to call the LIFX API. And wouldn’t you know it, someone has already created an npm package to do this called lifx-http-api. This is why you love JavaScript.
Setting the Bulb Hue
After the weather result comes back, I need to use the LIFX API instance and call the setState method. This method returns a promise which means that we need to nest promises. Nesting promises can get out of hand and could land us right back in callback hell, which is what we’re trying to avoid with promises in the first place.
Instead, we’ll handle the first promise and then return Promise.all which we can handle at another top-level then. This just prevents us from nesting then statements.
Remember kids, promises are just socially acceptable callbacks.
const axios = require('axios');
const LIFX = require('lifx-http-api');
let client = new LIFX({
bearerToken: process.env.LIFX_TOKEN
});
module.exports = function (context, myTimer) {
// build up the DarkSky endpoint
let endpoint = <code>${process.env.DS_API}/${process.env.DS_SECRET}/${
process.env.LAT
},${process.env.LNG}<code>;
// use axios to call DarkSky for weather
axios
.get(endpoint)
.then(response => {
let temp = Math.round(response.data.currently.temperature);
// make sure the temp isn't above 100 because that's as high as we can go
temp = temp < 100 ? temp : 100;
// determine the hue
let hue = 200 + (160 * (temp / 100));
// return Promise.all so we can resolve at the top level
return Promise.all([
data,
client.setState('all', { color: <code>hue:${hue}<code> })
]);
})
.then(result => {
// result[0] contains the darksky result
// result[1] contains the LIFX result
context.log(result[1]);
})
.catch(err => {
context.log(err.message);
});
};
Now we can run this thing locally and watch our timer do it’s thang.
That’s it! Let’s deploy it.
Deploying Weather Bulb
I can create a new Functions project from the VS Code extension.
I can right-click that to “Open in portal” where I can define a deployment source so it sucks my code in from Github and deploys it. This is ideal because now whenever I push a change to Github, my application automatically gets redeployed.
All Hail the Weather Bulb
Now just sit back and behold the soft glow of the Weather Bulb! Why look at the actual temperature when you can look at this beautiful shade of hot pink instead?
Can you guess what the temperature is based on what you know from this article? The person who leaves a comment and gets the closest will get a free LIFX lightbulb from me (because I ❤️ all of you), or the cost of the bulb if you are outside the U.S. (~$40).
You can grab all of the code for this project from Github.
And by that, it’s usually some kind of CSS experiment, often an elaborate drawing or interaction.
For example, have you seen Lynn Fisher’s extraordinary A Single Div project? Not only are all these graphics drawn in just HTML and CSS, they are all created with (you guessed it) a single <div></div>.
Why would she do that? Here’s one pertinent possibility: it’s none of our business. We’re free to wonder, or even ask if it’s done respectfully enough. But does it really matter? Let’s stop short of assuming she doesn’t know what’s she’s doing, assuming it’s a twisted form of pain, or that she’s unaware of other technologies. Check out the example where she drew the official SVG logo with CSS and a single div. Woke.
I even kinda get it. I wrote a whole book about SVG because I think it’s underused. Are there „CSS drawings” that I think would be better as SVG for a production site meant to last? Sure.
Jeepers creepers that’s something else. I would have guessed GreenSock was behind this at a quick glance. Speaking of, GreenSock has advocated right here on CSS-Tricks some techniques for smart animations. Part of that is breaking animations into parts and stitching them together into larger timelines for maintenance ease and „without getting bogged down by the process.”
So, did Julia Muzafarova do it wrong? Of course not. If there is a wrong way to animate a cartoon hipster on a bike in this world, I don’t wanna live here anymore. It’s 2,100 lines of meticulous positioning, coloring, and animating. Heck, it’ll work in some email clients if you really need to latch onto something „practical.”
Sasha Tran, a UI developer at Apple, shared her story of creating drawings in CSS last year. She drew something new everyday for 20 days during Codevember.
Even if I am not talented in hand illustrations, there is a way to express myself through other mediums. I found that medium to be in HTML and CSS. To level up and get to a point where I could create cute artwork, I focused on two things: the basics, and consistency. Working with basic CSS shapes like rectangles and basic properties like border-radius overtime gave me the muscle memory to progress into more intricate illustrations.
Significantly leveled up in a month and developed better CSS muscle memory. Huh. Speaking of shapes, there are plenty of ways to get tricky with those in CSS!
You could argue that pushing boundaries toward the impractical is what hones our skills for all that other work we have to do.
Dave Rupert shows us all how to animate radial progress bars in SVG with a tiny script alongside the stroke-dasharray and stroke-dashoffset properties:
For a client project we tasked ourselves with building out one of those cool radial progress bars. In the past, we’ve used entire Canvas-based charting libraries (156k/44k gzip), but that seemed like overkill. I looked at Airbnb’s Lottie project where you export After Effects animations as JSON. This is cool for complex animations, but the dependencies seemed heavy (248k/56k gzip) for one micro-animation.
Per the usual, I tried my hand at a minimal custom SVG with CSS animation and a small bit of JavaScript (~223b gzip). I’m pleased with the results.
Here’s another example Jeremias Menichelli posted here on CSS-Tricks with the added twist of making them components in React and Vue.
When I saw Chris’ article on notched boxes, I remembered that I got a challenge a while ago to CSS a design like the one below in a cross-browser manner:
What the challenge looked like.
It looks pretty similar to the concept of notched boxes, except the corners are now scooped and we only have to worry about one corner per box. So let’s see how we can do it, how we can expand the technique to multiple corners, what issues we run into and how we can get around them with or without making browser support compromises.
The initial idea: box-shadow!
We start with a box element:
<div class='box'></div>
We can give this some dimensions or let its dimensions be decided by the content—it doesn’t really matter. For simplicity, we’re just setting a max-width and a min-height on it. We’re also giving it an outline so we can see its boundaries.
Next, we absolutely position a square ::before pseudo-element whose edge length is equal to the diameter (or twice the radius $r) of the scoop in the corner. We also give this pseudo-element a reddish box-shadow and a dummy background (that we’ll remove later) just so that we can see it better:
$r: 2em;
.box {
position: relative;
/* same styles as before */
&:before {
position: absolute;
padding: $r;
box-shadow: 0 0 7px #b53;
background: #95a;
content: ''
}
}
Well, it doesn’t look too exciting… yet! So let’s move on and make this square a disc by setting border-radius: 50% on it and give it a negative margin equal to its radius $r, so that its central point coincides with the (0,0) point (top left corner) of its parent box. We also set overflow: hidden on the parent box, so that whatever of this pseudo-element is outside the .box gets cut out.
$r: 2em;
.box {
overflow: hidden;
/* same styles as before */
&:before {
/* same styles as before */
margin: -$r;
border-radius: 50%
}
}
Now we’re starting to see the shape we’ve been aiming for:
But it’s still not quite what we want. In order to get there, we use the fourth length value for the box-shadow property: the spread radius. If you need a refresher on how box-shadow works with these four values, you can check out the interactive demo below:
You may have already guessed what we do next. We remove the dummy background, we zero the first three box-shadow values (the x and y offsets and the blur radius) and use a pretty big number for the last one (the spread radius):
box-shadow: 0 0 0 300px;
The interactive demo below shows how increasing the spread radius makes it cover up more and more of its parent .box:
So, the trick here is having a spread radius sufficiently large so that it covers the rest of the parent element. The cool thing about this is that we can make the box-shadow semi-transparent or have rounded corners on the parent .box:
.box {
/* same styles as before */
border-radius: 1em;
&:before {
/* same styles as before */
box-shadow: 0 0 0 300px rgba(#95a, .75);
}
}
Of course, just like Chris pointed out in the article on notched boxes, we can make the scoop radius a CSS variable and then easily modify that from the JavaScript. Then everything updates nicely, even with text content in our box:
:root { --r: 50px }
.box {
/* same styles as before */
padding: var(--r);
&:before {
/* same styles as before */
margin: calc(-1*var(--r));
padding: inherit;
}
Note that when we also have text content, we need to set a negative z-index on the ::before pseudo-element and explicitly position it in the corner as we now also have a padding on the .box to compensate for the scoop.
.box {
/* same styles as before */
&:before {
/* same styles as before */
z-index: -1;
top: 0;
left: 0
}
Now, let’s move further and see how we can apply this concept in order to reproduce the design I showed at the beginning. In this particular case, the central points of the pseudo-element discs don’t coincide with box corners, but are outside, in the middle of the space in between boxes.
The structure used is pretty straightforward, just a <header> element followed by four <article> elements I’ve generated in a Pug loop:
while n--
article
h3 #{data[n].name}
section
p #{data[n].quote}
a(href='#') go
We use a wrapping flexbox layout on the <body> with the <header> really wide and with one or two <article> elements on each row, depending on how wide the viewport is.
Landscape (left) vs. portrait (right) mode.
If we have a single <article> on each row, we don’t have scooped corners, so their radius is 0px. Otherwise, we give this radius --r a non-zero value.
$min-w: 15rem; /* min width of an article element */
$m: 1rem; /* margin of such an element */
html { --r: 0px; }
article {
margin: $m;
min-width: $min-w;
width: 21em;
}
@media (min-width: 2*($min-w + 2*$m) /* enough for 2 per row */) {
html { --r: 4rem; }
article { width: 40%; }
}
Let’s now consider just the situation when we have two <article> elements per row (and of course a scooped corner for each because that’s what’s of interest to us).
In the case of the first one, we start with the leftmost limit of the disc along the right edge of its parent. That’s left: 100% so far. To move the x coordinate of the disc’s central point on the right edge of its parent, we subtract the disc’s radius, which brings us to left: calc(100% - var(--r)). But we don’t want it on the right edge, we want it offset to the right by the <article> margin $m, which brings us to the final value:
Along the y axis, we start with the topmost limit of the disc along the bottom edge of its parent—that’s top: 100%. To put the disc’s central point on the bottom edge of the parent box, we move it up by one radius, which gives us top: calc(100% - var(--r)). Finally, we want this central point to be $m below the parent’s bottom edge, which gives us the final vertical offset of:
Horizontally however, we start with the disc’s left limit being along its parent’s left edge—that’s left: 0%. To put the disc’s central point on its parent’s left edge, we move it left by a radius --r, thus getting left: calc(0% - var(--r)). However, the final position is $m to the left of the parent’s left edge:
Vertically, we start with the disc’s top limit along the top edge of its parent—that’s top: 0%. To put the disc’s central point on the parent’s top edge, we move it up by a radius --r, thus getting top: calc(0% - var(--r)). But we want to have it $m above the parent’s top edge, so the final top offset is:
For the final one (second on the last row), we have the same horizontal offset as in the case of the one above it and the same vertical offset as for the one to its left on the same row.
This means the positions of the central points of the discs depend on the gap in between our <article> elements (this gap is twice the margin: $m we set on them), on the disc radius r and on a couple of horizontal and vertical multipliers (--i and --j respectively). Both these multipliers are initially -1.
For the first two <article> elements (on the first row of the 2x2 grid), we change the vertical multiplier --j to 1 because we want the y coordinate of the discs’ central points to be below the bottom edge, while for the odd ones (on the first column), we change the horizontal multiplier --i to 1 because we want the x coordinate to be to the right of the right edge.
html { --i: -1; --j: -1 } /* multipliers initially set to -1 */
h3, section {
&:before {
/* set generic offsets */
top: calc((1 + var(--j))*50% - var(--r) + var(--j)*#{$m});
left: calc((1 + var(--i))*50% - var(--r) + var(--i)*#{$m});
}
}
@media (min-width: 2*($min-w + 2*$m)) {
article {
/* change vertical multiplier for first two (on 1st row of 2x2 grid) */
&:nth-of-type(-n + 2) { --j: 1 }
/* change horizontal multiplier for odd ones (on 1st column) */
&:nth-of-type(odd) { --i: 1 }
}
Note that we only have visible disc cutouts on the <section> element for the first two <article> elements and only on the <h3> for the last two. So for the first two <article> elements, the radius --r on the heading’s ::before pseudo-element is 0, while for the last two, this radius is 0 for the section’s ::before pseudo:
The above demo works in current versions of all major browsers and, if we can do with some repetition instead of using CSS variables, we can extend support all the way back to IE9.
Potential issues with the above method
While this was a quick and easy cross-browser way to get the desired result in this particular case, we may not always be so lucky with this approach.
First off, we need a pseudo-element for each scooped corner, so if we want this effect for all corners, we need to bring in an extra element. Sad panda.
Secondly, we may not always want a solid background. We may want a semi-transparent one (which becomes a pain to get if we want to have more than one scooped corner), a gradient one (while we can emulate some radial gradients with box-shadow, it’s a less than ideal solution) or even an image background (hardly doable with the only solution being to use mix-blend-mode which cuts out Edge support without an elegant fallback).
And how about really large boxes for which the spread we’ve set is not enough? Ugh.
So, let’s explore other, more reliable approaches with various degrees of browser support.
Flexibility and good browser support? SVG it!
This is probably no surprise, but the full SVG solution fares best if we want something flexible and reliably cross-browser today. It’s a solution that involves using an SVG element before the content of our box. This SVG contains a <circle> on which we’ve set a radius r attribute.
<div class='box'>
<svg>
<circle r='50'/>
</svg>
TEXT CONTENT OF BOX GOES HERE
</div>
We absolutely position this SVG within the box and size it such that it fully covers its parent:
Alright, but what we’ve done here is create circles in the corners and what we actually want is… the exact opposite! What we do next is put these circles within a <mask>, on top of a white, full-size (covering the whole SVG) rectangle and then we use this mask on another full size rectangle:
If we have text, we need to adapt the box padding to our corner radius, setting the it to the same value as we’ve set the radius of the SVG circle, using JavaScript to keep them in sync:
Of course, the fill of our background rectangle doesn’t need to be a solid one. It may well be semi-transparent (as it is in the demo above), or we can use an SVG gradient or pattern for it. The latter would also allow us to use one or more background images.
Well, glad you asked! There are a number of things we can do here to shift the weight of the masking method from SVG to CSS.
Sadly, none of these is cross-browser, but they simplify things and they’re definitely something to keep a watch for in the near or more distant future.
Use CSS masking on HTML elements instead
What we do here is remove everything outside the mask from the SVG. Then, from the CSS, we set a background (which can be semi-transparent, a CSS gradient, an image, a combination of multiple backgrounds… anything that CSS has to offer) and the mask property on the .box element:
.box {
/* any kind of background we wish */
mask: url(#m);
}
Note that setting an inline SVG mask on an HTML element only works in Firefox for now!
Version using CSS masking directly on our .box (live demo, Firefox only).
Set the circle radius from the CSS
This means removing the r attribute from our <circle> and setting it in the CSS to the same variable as the box padding:
This way, when we change the value of --r, both the scoop radius and the padding around the .box content get updated!
Note that setting geometry properties for SVG elements from the CSS only works in Blink browsers for now!
Version using a CSS variable for the <circle> radius (live demo, Blink only).
Combine the previous two methods
While this would be cool, it’s sadly not possible in practice in any browser at the moment. But the good news is we can do even better than that!
Use CSS gradients for masking
Note that CSS masking on HTML elements doesn’t work at all in Edge at this point, though it’s listed as „In Development” and a flag for it (that doesn’t do anything for now) has already shown up in about:flags.
We ditch the SVG part completely and start building our CSS gradient mask. We create the circles at the corners using radial gradients. The following CSS creates a circle of radius --r in the top left corner of a box:
.box {
/* same as before */
/* any CSS background we wish */
mask: radial-gradient(circle at 0 0, #000 var(--r, 50px), transparent 0);
}
Note that WebKit browsers still need the -webkit- prefix for the mask properties.
We then add the circles at the other corners:
$grad-list: radial-gradient(circle at 0 0 , #000 var(--r, 50px), transparent 0),
radial-gradient(circle at 100% 0 , #000 var(--r, 50px), transparent 0),
radial-gradient(circle at 0 100%, #000 var(--r, 50px), transparent 0),
radial-gradient(circle at 100% 100%, #000 var(--r, 50px), transparent 0);
.box {
/* same as before */
/* any CSS background we wish */
mask: $grad-list
}
That’s insanely repetitive, either a lot of writing or a lot of copy-pasting, so let’s see what we can do about that.
First off, we use a CSS variable for the stop list. This eliminates repetition in the generated CSS.
$grad-list: radial-gradient(circle at 0 0 , var(--stop-list)),
radial-gradient(circle at 100% 0 , var(--stop-list)),
radial-gradient(circle at 0 100%, var(--stop-list)),
radial-gradient(circle at 100% 100%, var(--stop-list));
.box {
/* same as before */
/* any CSS background we wish */
--stop-list: #000 var(--r, 50px), transparent 0;
mask: $grad-list;
}
But it’s still not much better, so let’s generate the corners within a loop:
$grad-list: ();
@for $i from 0 to 4 {
$grad-list: $grad-list,
radial-gradient(circle at ($i%2)*100% floor($i/2)*100%, var(--stop-list));
}
.box {
/* same as before */
/* any CSS background we wish */
--stop-list: #000 var(--r, 50px), transparent 0;
mask: $grad-list;
}
Much better as far as the code goes because now we don’t have to write anything multiple times and run the risk of not updating everywhere later. But the result so far isn’t what we were going for:
Result of the code above (live demo, no Edge support for now).
Here, we’re cutting out everything but the corners, which is the opposite of what we want.
One thing we can do is reverse the gradients, make the corner circles transparent and the rest black with:
--stop-list: transparent var(--r, 50px), #000 0;
This does the trick when we use just one gradient for just one corner:
Result when using just one gradient (live demo, no Edge support for now).
However, when we stack up all four of them (or just even two), we get a black rectangle the size of our box for the mask, which means nothing actually gets masked out anymore.
Layering mask gradients (live demo, no Edge support for now).
So, we restrict each of these gradients to a quarter of our box – 50% of the width and 50% of the height, thus getting 25% (a quarter) of the area for each:
This means we also need to set a mask-size of 50% 50%, a mask-repeat of no-repeat, and position each mask-image into the desired corner:
$grad-list: ();
@for $i from 0 to 4 {
$x: ($i%2)*100%;
$y: floor($i/2)*100%;
$grad-list: $grad-list
radial-gradient(circle at $x $y, var(--stop-list)) /* mask image */
$x $y; /* mask position */
}
.box {
/* same as before */
/* any CSS background we wish */
--stop-list: transparent var(--r, 50px), #000 0;
mask: $grad-list;
mask-size: 50% 50%;
mask-repeat: no-repeat;
}
Note that WebKit browsers still need the -webkit- prefix for mask properties.
But the big problem here is… the problem with division and rounding in general—our four quarters put together don’t always manage to make up a whole again, so we end up with gaps in between them.
Sadly, we may get gaps in between the four quarters (live demo).
Oh well, it’s not like we can’t cover up those gaps with thin linear-gradient() strips or increase the mask-size to let’s say 51%:
Increasing the mask-size for each gradient layer fixes the problem of gaps (live demo).
But isn’t there a more elegant way?
Well, there’s a mask-composite property that can help us if we set it to intersect when reverting back to the full size gradient layers.
$grad-list: ();
@for $i from 0 to 4 {
$grad-list: $grad-list,
radial-gradient(circle at ($i%2)*100% floor($i/2)*100%, var(--stop-list));
}
.box {
/* same as before */
/* any CSS background we wish */
--stop-list: transparent var(--r, 50px), #000 0;
mask: $grad-list;
mask-composite: exclude;
}
This is extremely cool because it’s a pure CSS, no SVG solution, but the not-so-good news is that support is limited to Firefox 53+ here.
Result using mask-composite: intersect (live demo).
However, it’s still better than support for the final option we have when it comes to scooped corners.
The corner-shape option
Lea Verou came up with this idea some five years ago and even created a preview page for it. Sadly, not only is it not implemented by any browser yet, but the spec hasn’t advanced much in the meanwhile. It’s still something to keep in mind for the future, as it offers a lot of flexibility with very little code – recreating our effect would only require the following:
There have long been multiple implementations of Sass. Most notably, the canonical Ruby version, now at 3.5.6. Then there is LibSass, the C++ version, which is at version 3.4 and…
Current LibSass 3.4 should be compatible with Sass 3.4.
LibSass is notable because it powers the majority of Sass ports. Over 30 of them, apparently, including the most popular one: node-sass, which provides Sass for the bajillion projects out there that wanna run an npm-y JavaScript-based dev environment and avoid the Ruby dependency.
It’s a little unfortunate LibSass isn’t up-to-date with current canonical Sass, but I think it’s on freeze as it’s been stated that LibSass will never be canonical Sass. Update: it’s not on freeze. It was actually Ruby Sass that was once on freeze with the intention of allowing LibSass to catch up. As I write, LibSass is at 3.5.2, so it’s close.
Dart Sass just went 1.0.0, and is now 100% compatible with Ruby Sass 3.5.6. They announced that Ruby Sass has now begun deprecation and—after March 26th, 2019—will no longer be maintained.
The future of Dart Sass looks pretty good:
Another big announcement: as of today, I'm working full-time on @SassCSS. This has been a goal for my entire career and I'm thrilled that it's finally happening
The Dart Sass compatibility is also great, because node-sass can now switch to Dart Sass bindings and become entirely up to date. Will it? I have no idea. The maintainer of LibSass and node-sass is the same person (Michael Mifsud), and with 30+ bindings to LibSass, I can’t imagine LibSass just going away. I guess we’ll just have to wait and see a while. I gotta imagine someone will jump on making a node version of Dart Sass one way or another.
I, for one, would love to see a Web Worker version.
![Animated gif. Shows the graphical representation of the cubic Bézier curve, with start point at (0, 0), end point at (1, 1) and control points at (1, 1.59) and (.61, .74), the progression on the [0, 1] interval being a function of time in the [0, 1] interval. Also illustrates how the transition function given by this cubic Bézier curve looks when applied on a translation compared to a plain ease-out.](https://cdn.css-tricks.com/wp-content/uploads/2018/03/bounce_css.gif)
