CSS Container Queries are still gaining traction and many of us are getting our hands wet with them, even if it’s for little experiments or whatnot. They’ve got great, but not quite full, browser support — enough to justify using them in some projects, but maybe not to the extent where we might be tempted to start replacing media queries from past projects with shiny new container size queries.
They sure are handy though! In fact, I’ve already run into a few situations where I really wanted to reach for them but just couldn’t overcome the support requirements. If I had been able to use them, this is how it would have looked in those situations.
All of the following demos will be best viewed in Chrome or Safari at the time of this writing. Firefox plans to ship support in Version 109.
Case 1: Card grid
You kind of had to expect this one, right? It’s such a common pattern that all of us seem to run into it at some point. But the fact is that container size queries would have been a huge time-saver for me with a better outcome had I been able to use them over standard media queries.
Let’s say you’ve been tasked with building this card grid with the requirement that each card needs to keep it’s 1:1 aspect ratio:
It’s tougher than it looks! The problem is that sizing a component’s contents on the viewport’s width leaves you at the mercy of how the component responds to the viewport — as well the way any other ancestor containers respond to it. If, for example, you want the font size of a card heading to reduce when the card hits a certain inline size there’s no reliable way to do it.
You could set the font size in vw units, I suppose, but the component is still tied to the browser’s viewport width. And that can cause problems when the card grid is used other in contexts that may not have the same breakpoints.
In my real-world project, I landed on a JavaScript approach that would:
Listen for a resize event.
Calculate the width of each card.
Add an inline font size to each card based on its width.
Style everything inside using em units.
Seems like a lot of work, right? But it is a stable solution to get the required scaling across different screen sizes in different contexts.
Container queries would have been so much better because they provide us with container query units, such as the cqw unit. You probably already get it, but 1cqw is equal to 1% of a container’s width. We also have the cqi unit that’s a measure of a container’s inline width, and cqb for a container’s block width. So, if we have a card container that is 500px wide, a 50cqw value computes to 250px.
If I had been able to use container queries in my card grid, I could have set up the .card component as a container:
.card {
container: card / size;
}
Then I could have set an inner wrapper with padding that scales at 10% of the .card‘s width using the cqw unit:
.card__inner {
padding: 10cqw;
}
That’s a nice way to scale the spacing between the card’s edges and its contents consistently no matter where the card is used at any given viewport width. No media queries required!
Another idea? Use cqw units for the font size of the inner contents, then apply padding in em units:
.card__inner {
font-size: 5cqw;
padding: 2em;
}
5cqw is an arbitrary value — just one that I settled on. That padding is still equal to 10cqw since the em unit is relative to the .card__inner font size!
Did you catch that? The 2em is relative to the 5cqw font size that is set on the same container. Containers work different than what we’re used to, as em units are relative to the same element’s font-size value. But what I quickly noticed is that container query units relate to the nearest parent that is also a container.
For example, 5cqw does not scale based on the .card element’s width in this example:
Rather, it scales to whatever the nearest parent that’s defined as a container. That’s why I set up a .card__inner wrapper.
Case 2: Alternating layout
I needed yet another card component in a different project. This time, I needed the card to transition from a landscape layout to a portrait layout… then back to landscape, and back to portrait again as the screen gets smaller.
I did the dirty work of making this component go to portrait at those two specific viewport ranges (shout out to the new media query range syntax!), but again, the problem is that it is then locked to the media queries set on it, its parent, and anything else that might respond to the viewport’s width. We want something that works in any condition without worrying about wondering where the content is going to break!
Container queries would have made this a breeze, thanks to the @container rule:
But hold on! There’s something you might want to watch out for. Specifically, it could be difficult to use a container query like this within a prop-based design system. For example, this .info-card component could contain child components that rely on props to change their appearance.
Why’s that a big deal? The card’s portrait layout might require the alternate styling but you can’t change JavaScript props with CSS. As such, you risk duplicating the required styles. I actually touched on this and how to work around it in another article. If you need to use container queries for a significant amount of your styling, then you may need to base your entire design system around them rather than trying to shoehorn them into an existing design system that’s heavy on media queries.
Case 3: SVG strokes
Here’s another super common pattern I’ve recently used where container size queries would have resulted in a more polished product. Say you have an icon locked up with a heading:
It’s pretty straightforward to scale the icon with the title’s size, even without media queries. The problem, though, is that the SVG’s stroke-width might get too thin to be noticed all that well at a smaller size, and perhaps catch too much attention with a super thick stroke at a larger size.
I’ve had to create and apply classes to each icon instance to determine its size and stroke width. That’s OK if the icon is next to a heading that’s styled with a fixed font size, I guess, but it’s not so great when working with fluid type that constantly changes.
The heading’s font size might be based on the viewport’s width, so the SVG icon needs to adjust accordingly where its stroke works at any size. You could make the stroke width relative to the heading’s font-size by setting it in em units. But if you have a specific set of stroke sizes that you need to stick to, then this wouldn’t work because it otherwise scales linearly — there’s no way to adjust it to a specific stroke-width value at certain points without resorting to media queries on the viewport width.
But here’s what I would have done if I had the luxury of container queries at that time:
Compare the implementations and see how the container query version snaps the SVG’s stroke to the specific widths I want based on the container’s width.
Bonus: Other types of container size queries
OK, so I haven’t actually run into this on a real project. But as I was combing through information on container queries, I noticed that there are additional things we can query on a container that are related to the container’s size or physical dimensions.
Most examples I’ve seen query the width, max-width, and min-width, height, block-size, and inline-size as I’ve been doing throughout this article.
But MDN outlines two more things we can query against. One is orientation which makes perfect sense because we use it all the time in media queries. It’s no different with container queries:
Here’s an editable demo to play around with both examples:
I haven’t really found a good use case for either of these yet. If you have any ideas or feel like it could’ve helped you in your projects, let me know in the comments!
Today we’ll walk through the creation of a 3D packaging box that folds and unfolds on scroll. We’ll be using Three.js and GSAP for this.
We won’t use any textures or shaders to set it up. Instead, we’ll discover some ways to manipulate the Three.js BufferGeometry.
This is what we will be creating:
Scroll-driven animation
We’ll be using GSAP ScrollTrigger, a handy plugin for scroll-driven animations. It’s a great tool with a good documentation and an active community so I’ll only touch the basics here.
Let’s set up a minimal example. The HTML page contains:
a full-screen <canvas> element with some styles that will make it cover the browser window
a <div class=”page”> element behind the <canvas>. The .page element a larger height than the window so we have a scrollable element to track.
On the <canvas> we render a 3D scene with a box element that rotates on scroll.
To rotate the box, we use the GSAP timeline which allows an intuitive way to describe the transition of the box.rotation.x property.
gsap.timeline({})
.to(box.rotation, {
duration: 1, // <- takes 1 second to complete
x: .5 * Math.PI,
ease: 'power1.out'
}, 0) // <- starts at zero second (immediately)
The x value of the box.rotation is changing from 0 (or any other value that was set before defining the timeline) to 90 degrees. The transition starts immediately. It has a duration of one second and power1.out easing so the rotation slows down at the end.
Once we add the scrollTrigger to the timeline, we start tracking the scroll position of the .page element (see properties trigger, start, end). Setting the scrub property to true makes the transition not only start on scroll but actually binds the transition progress to the scroll progress.
Now box.rotation.x is calculated as a function of the scroll progress, not as a function of time. But the easing and timing parameters still matter. Power1.out easing still makes the rotation slower at the end (check out ease visualiser tool and try other options to see the difference). Start and duration values don’t mean seconds anymore but they still define the sequence of the transitions within the timeline.
For example, in the following timeline the last transition is finished at 2.3 + 0.7 = 3.
gsap.timeline({
scrollTrigger: {
// ...
},
})
.to(box.rotation, {
duration: 1,
x: .5 * Math.PI,
ease: 'power1.out'
}, 0)
.to(box.rotation, {
duration: 0.5,
x: 0,
ease: 'power2.inOut'
}, 1)
.to(box.rotation, {
duration: 0.7, // <- duration of the last transition
x: - Math.PI,
ease: 'none'
}, 2.3) // <- start of the last transition
We take the total duration of the animation as 3. Considering that, the first rotation starts once the scroll starts and takes ⅓ of the page height to complete. The second rotation starts without any delay and ends right in the middle of the scroll (1.5 of 3). The last rotation starts after a delay and ends when we scroll to the end of the page. That’s how we can construct the sequences of transitions bound to the scroll.
To get further with this tutorial, we don’t need more than some basic understanding of GSAP timing and easing. Let me just mention a few tips about the usage of GSAP ScrollTrigger, specifically for a Three.js scene.
Tip #1: Separating 3D scene and scroll animation
I found it useful to introduce an additional variable params = { angle: 0 } to hold animated parameters. Instead of directly changing rotation.x in the timeline, we animate the properties of the “proxy” object, and then use it for the 3D scene (see the updateSceneOnScroll() function under tip #2). This way, we keep scroll-related stuff separate from 3D code. Plus, it makes it easier to use the same animated parameter for multiple 3D transforms; more about that a bit further on.
Tip #2: Render scene only when needed
Maybe the most common way to render a Three.js scene is calling the render function within the window.requestAnimationFrame() loop. It’s good to remember that we don’t need it, if the scene is static except for the GSAP animation. Instead, the line renderer.render(scene, camera) can be simply added to to the onUpdate callback so the scene is redrawing only when needed, during the transition.
// No need to render the scene all the time
// function animate() {
// requestAnimationFrame(animate);
// // update objects(s) transforms here
// renderer.render(scene, camera);
// }
let params = { angle: 0 }; // <- "proxy" object
// Three.js functions
function updateSceneOnScroll() {
box.rotation.x = angle.v;
renderer.render(scene, camera);
}
// GSAP functions
function createScrollAnimation() {
gsap.timeline({
scrollTrigger: {
// ...
onUpdate: updateSceneOnScroll
},
})
.to(angle, {
duration: 1,
v: .5 * Math.PI,
ease: 'power1.out'
})
}
Tip #3: Three.js methods to use with onUpdate callback
Various properties of Three.js objects (.quaternion, .position, .scale, etc) can be animated with GSAP in the same way as we did for rotation. But not all the Three.js methods would work.
Some of them are aimed to assign the value to the property (.setRotationFromAxisAngle(), .setRotationFromQuaternion(), .applyMatrix4(), etc.) which works perfectly for GSAP timelines.
But other methods add the value to the property. For example, .rotateX(.1) would increase the rotation by 0.1 radians every time it’s called. So in case box.rotateX(angle.v) is placed to the onUpdate callback, the angle value will be added to the box rotation every frame and the 3D box will get a bit crazy on scroll. Same with .rotateOnAxis, .translateX, .translateY and other similar methods – they work for animations in the window.requestAnimationFrame() loop but not as much for today’s GSAP setup.
Note: This Three.js scene and other demos below contain some additional elements like axes lines and titles. They have no effect on the scroll animation and can be excluded from the code easily. Feel free to remove the addAxesAndOrbitControls() function, everything related to axisTitles and orbits, and <div> classed ui-controls to get a truly minimal setup.
Now that we know how to rotate the 3D object on scroll, let’s see how to create the package box.
Box structure
The box is composed of 4 x 3 = 12 meshes:
We want to control the position and rotation of those meshes to define the following:
unfolded state
folded state
closed state
For starters, let’s say our box doesn’t have flaps so all we have is two width-sides and two length-sides. The Three.js scene with 4 planes would look like this:
let box = {
params: {
width: 27,
length: 80,
depth: 45
},
els: {
group: new THREE.Group(),
backHalf: {
width: new THREE.Mesh(),
length: new THREE.Mesh(),
},
frontHalf: {
width: new THREE.Mesh(),
length: new THREE.Mesh(),
}
}
};
scene.add(box.els.group);
setGeometryHierarchy();
createBoxElements();
function setGeometryHierarchy() {
// for now, the box is a group with 4 child meshes
box.els.group.add(box.els.frontHalf.width, box.els.frontHalf.length, box.els.backHalf.width, box.els.backHalf.length);
}
function createBoxElements() {
for (let halfIdx = 0; halfIdx < 2; halfIdx++) {
for (let sideIdx = 0; sideIdx < 2; sideIdx++) {
const half = halfIdx ? 'frontHalf' : 'backHalf';
const side = sideIdx ? 'width' : 'length';
const sideWidth = side === 'width' ? box.params.width : box.params.length;
box.els[half][side].geometry = new THREE.PlaneGeometry(
sideWidth,
box.params.depth
);
}
}
}
All 4 sides are by default centered in the (0, 0, 0) point and lying in the XY-plane:
Folding animation
To define the unfolded state, it’s sufficient to:
move panels along X-axis aside from center so they don’t overlap
Transforming it to the folded state means
rotating width-sides to 90 deg around Y-axis
moving length-sides to the opposite directions along Z-axis
moving length-sides along X-axis to keep the box centered
Aside of box.params.width, box.params.length and box.params.depth, the only parameter needed to define these states is the opening angle. So the box.animated.openingAngle parameter is added to be animated on scroll from 0 to 90 degrees.
Nice! Let’s think about the flaps. We want them to move together with the sides and then to rotate around their own edge to close the box.
To move the flaps together with the sides we simply add them as the children of the side meshes. This way, flaps inherit all the transforms we apply to the sides. An additional position.y transition will place them on top or bottom of the side panel.
let box = {
params: {
// ...
},
els: {
group: new THREE.Group(),
backHalf: {
width: {
top: new THREE.Mesh(),
side: new THREE.Mesh(),
bottom: new THREE.Mesh(),
},
length: {
top: new THREE.Mesh(),
side: new THREE.Mesh(),
bottom: new THREE.Mesh(),
},
},
frontHalf: {
width: {
top: new THREE.Mesh(),
side: new THREE.Mesh(),
bottom: new THREE.Mesh(),
},
length: {
top: new THREE.Mesh(),
side: new THREE.Mesh(),
bottom: new THREE.Mesh(),
},
}
},
animated: {
openingAngle: .02 * Math.PI
}
};
scene.add(box.els.group);
setGeometryHierarchy();
createBoxElements();
function setGeometryHierarchy() {
// as before
box.els.group.add(box.els.frontHalf.width.side, box.els.frontHalf.length.side, box.els.backHalf.width.side, box.els.backHalf.length.side);
// add flaps
box.els.frontHalf.width.side.add(box.els.frontHalf.width.top, box.els.frontHalf.width.bottom);
box.els.frontHalf.length.side.add(box.els.frontHalf.length.top, box.els.frontHalf.length.bottom);
box.els.backHalf.width.side.add(box.els.backHalf.width.top, box.els.backHalf.width.bottom);
box.els.backHalf.length.side.add(box.els.backHalf.length.top, box.els.backHalf.length.bottom);
}
function createBoxElements() {
for (let halfIdx = 0; halfIdx < 2; halfIdx++) {
for (let sideIdx = 0; sideIdx < 2; sideIdx++) {
// ...
const flapWidth = sideWidth - 2 * box.params.flapGap;
const flapHeight = .5 * box.params.width - .75 * box.params.flapGap;
// ...
const flapPlaneGeometry = new THREE.PlaneGeometry(
flapWidth,
flapHeight
);
box.els[half][side].top.geometry = flapPlaneGeometry;
box.els[half][side].bottom.geometry = flapPlaneGeometry;
box.els[half][side].top.position.y = .5 * box.params.depth + .5 * flapHeight;
box.els[half][side].bottom.position.y = -.5 * box.params.depth -.5 * flapHeight;
}
}
}
The flaps rotation is a bit more tricky.
Changing the pivot point of Three.js mesh
Let’s get back to the first example with a Three.js object rotating around the X axis.
There’re many ways to set the rotation of a 3D object: Euler angle, quaternion, lookAt() function, transform matrices and so on. Regardless of the way angle and axis of rotation are set, the pivot point (transform origin) will be at the center of the mesh.
Say we animate rotation.x for the 4 boxes that are placed around the scene:
const boxGeometry = new THREE.BoxGeometry(boxSize[0], boxSize[1], boxSize[2]);
const boxMesh = new THREE.Mesh(boxGeometry, boxMaterial);
const numberOfBoxes = 4;
for (let i = 0; i < numberOfBoxes; i++) {
boxes[i] = boxMesh.clone();
boxes[i].position.x = (i - .5 * numberOfBoxes) * (boxSize[0] + 2);
scene.add(boxes[i]);
}
boxes[1].position.y = .5 * boxSize[1];
boxes[2].rotation.y = .5 * Math.PI;
boxes[3].position.y = - boxSize[1];
For them to rotate around the bottom edge, we need to move the pivot point to -.5 x box size. There are couple of ways to do this:
wrap mesh with additional Object3D
transform geometry of mesh
assign pivot point with additional transform matrix
could be some other tricks
If you’re curious why Three.js doesn’t provide origin positioning as a native method, check out this discussion.
Option #1: Wrapping mesh with additional Object3D
For the first option, we add the original box mesh as a child of new Object3D. We treat the parent object as a box so we apply transforms (rotation.x) to it, exactly as before. But we also translate the mesh to half of its size. The mesh moves up in the local space but the origin of the parent object stays in the same point.
const boxGeometry = new THREE.BoxGeometry(boxSize[0], boxSize[1], boxSize[2]);
const boxMesh = new THREE.Mesh(boxGeometry, boxMaterial);
const numberOfBoxes = 4;
for (let i = 0; i < numberOfBoxes; i++) {
boxes[i] = new THREE.Object3D();
const mesh = boxMesh.clone();
mesh.position.y = .5 * boxSize[1];
boxes[i].add(mesh);
boxes[i].position.x = (i - .5 * numberOfBoxes) * (boxSize[0] + 2);
scene.add(boxes[i]);
}
boxes[1].position.y = .5 * boxSize[1];
boxes[2].rotation.y = .5 * Math.PI;
boxes[3].position.y = - boxSize[1];
The idea and result are the same: we move the mesh up ½ of its height but the origin point is staying at the same coordinates. That’s why rotation.x transform makes the box rotate around its bottom side.
Option #3: Assign pivot point with additional transform matrix
I find this way less suitable for today’s project but the idea behind it is pretty simple. We take both, pivot point position and desired transform as matrixes. Instead of simply applying the desired transform to the box, we apply the inverted pivot point position first, then do rotation.x as the box is centered at the moment, and then apply the point position.
You can find a nice implementation of this method here.
I’m using geometry translation (option #2) to move the origin of the flaps. Before getting back to the box, let’s see what we can achieve if the very same rotating boxes are added to the scene in hierarchical order and placed one on top of another.
const boxGeometry = new THREE.BoxGeometry(boxSize[0], boxSize[1], boxSize[2]);
boxGeometry.translate(0, .5 * boxSize[1], 0);
const boxMesh = new THREE.Mesh(boxGeometry, boxMaterial);
const numberOfBoxes = 4;
for (let i = 0; i < numberOfBoxes; i++) {
boxes[i] = boxMesh.clone();
if (i === 0) {
scene.add(boxes[i]);
} else {
boxes[i - 1].add(boxes[i]);
boxes[i].position.y = boxSize[1];
}
}
We still animate rotation.x of each box from 0 to 90 degrees, so the first mesh rotates to 90 degrees, the second one does the same 90 degrees plus its own 90 degrees rotation, the third does 90+90+90 degrees, etc.
Back to the flaps. Flaps are made from translated geometry and added to the scene as children of the side meshes. We set their position.y property once and animate their rotation.x property on scroll.
With all this, we finish the animation part! Let’s now work on the look of our box.
Lights and colors
This part is as simple as replacing multi-color wireframes with a single color MeshStandardMaterial and adding a few lights.
const ambientLight = new THREE.AmbientLight(0xffffff, .5);
scene.add(ambientLight);
lightHolder = new THREE.Group();
const topLight = new THREE.PointLight(0xffffff, .5);
topLight.position.set(-30, 300, 0);
lightHolder.add(topLight);
const sideLight = new THREE.PointLight(0xffffff, .7);
sideLight.position.set(50, 0, 150);
lightHolder.add(sideLight);
scene.add(lightHolder);
const material = new THREE.MeshStandardMaterial({
color: new THREE.Color(0x9C8D7B),
side: THREE.DoubleSide
});
box.els.group.traverse(c => {
if (c.isMesh) c.material = material;
});
Tip: Object rotation effect with OrbitControls
OrbitControls make the camera orbit around the central point (left preview). To demonstrate a 3D object, it’s better to give users a feeling that they rotate the object itself, not the camera around it (right preview). To do so, we keep the lights position static relative to camera.
It can be done by wrapping lights in an additional lightHolder object. The pivot point of the parent object is (0, 0, 0). We also know that the camera rotates around (0, 0, 0). It means we can simply apply the camera’s rotation to the lightHolder to keep the lights static relative to the camera.
function render() {
// ...
lightHolder.quaternion.copy(camera.quaternion);
renderer.render(scene, camera);
}
So far, our sides and flaps were done as a simple PlaneGeomery. Let’s replace it with “real” corrugated cardboard material ‐ two covers and a fluted layer between them.
First step is replacing a single plane with 3 planes merged into one. To do so, we need to place 3 clones of PlaneGeometry one behind another and translate the front and back levels along the Z axis by half of the total cardboard thickness.
There’re many ways to move the layers, starting from the geometry.translate(0, 0, .5 * thickness) method we used to change the pivot point. But considering other transforms we’re about to apply to the cardboard geometry, we better go through the geometry.attributes.position array and add the offset to the z-coordinates directly:
fconst baseGeometry = new THREE.PlaneGeometry(
params.width,
params.height,
);
const geometriesToMerge = [
getLayerGeometry(- .5 * params.thickness),
getLayerGeometry(0),
getLayerGeometry(.5 * params.thickness)
];
function getLayerGeometry(offset) {
const layerGeometry = baseGeometry.clone();
const positionAttr = layerGeometry.attributes.position;
for (let i = 0; i < positionAttr.count; i++) {
const x = positionAttr.getX(i);
const y = positionAttr.getY(i)
const z = positionAttr.getZ(i) + offset;
positionAttr.setXYZ(i, x, y, z);
}
return layerGeometry;
}
For merging the geometries we use the mergeBufferGeometries method. It’s pretty straightforward, just don’t forget to import the BufferGeometryUtils module into your project.
To turn a mid layer into the flute, we apply the sine wave to the plane. In fact, it’s the same z-coordinate offset, just calculated as Sine function of the x-attribute instead of a constant value.
function getLayerGeometry() {
const baseGeometry = new THREE.PlaneGeometry(
params.width,
params.height,
params.widthSegments,
1
);
const offset = (v) => .5 * params.thickness * Math.sin(params.fluteFreq * v);
const layerGeometry = baseGeometry.clone();
const positionAttr = layerGeometry.attributes.position;
for (let i = 0; i < positionAttr.count; i++) {
const x = positionAttr.getX(i);
const y = positionAttr.getY(i)
const z = positionAttr.getZ(i) + offset(x);
positionAttr.setXYZ(i, x, y, z);
}
layerGeometry.computeVertexNormals();
return layerGeometry;
}
The z-offset is not the only change we need here. By default, PlaneGeometry is constructed from two triangles. As it has only one width segment and one height segment, there’re only corner vertices. To apply the sine(x) wave, we need enough vertices along the x axis – enough resolution, you can say.
Also, don’t forget to update the normals after changing the geometry. It doesn’t happen automatically.
I apply the wave with an amplitude equal to the cardboard thickness to the middle layer, and the same wave with a little amplitude to the front and back layers, just to give some texture to the box.
The surfaces and cuts look pretty cool. But we don’t want to see the wavy layer on the folding lines. At the same time, I want those lines to be visible before the folding happens:
To achieve this, we can “press” the cardboard on the selected edges of each panel.
We can do so by applying another modifier to the z-coordinate. This time it’s a power function of the x or y attribute (depending on the side we’re “pressing”).
function getLayerGeometry() {
const baseGeometry = new THREE.PlaneGeometry(
params.width,
params.height,
params.widthSegments,
params.heightSegments // to apply folding we need sufficient number of segments on each side
);
const offset = (v) => .5 * params.thickness * Math.sin(params.fluteFreq * v);
const layerGeometry = baseGeometry.clone();
const positionAttr = layerGeometry.attributes.position;
for (let i = 0; i < positionAttr.count; i++) {
const x = positionAttr.getX(i);
const y = positionAttr.getY(i)
let z = positionAttr.getZ(i) + offset(x); // add wave
z = applyFolds(x, y, z); // add folds
positionAttr.setXYZ(i, x, y, z);
}
layerGeometry.computeVertexNormals();
return layerGeometry;
}
function applyFolds(x, y, z) {
const folds = [ params.topFold, params.rightFold, params.bottomFold, params.leftFold ];
const size = [ params.width, params.height ];
let modifier = (c, size) => (1. - Math.pow(c / (.5 * size), params.foldingPow));
// top edge: Z -> 0 when y -> plane height,
// bottom edge: Z -> 0 when y -> 0,
// right edge: Z -> 0 when x -> plane width,
// left edge: Z -> 0 when x -> 0
if ((x > 0 && folds[1]) || (x < 0 && folds[3])) {
z *= modifier(x, size[0]);
}
if ((y > 0 && folds[0]) || (y < 0 && folds[2])) {
z *= modifier(y, size[1]);
}
return z;
}
The folding modifier is applied to all 4 edges of the box sides, to the bottom edges of the top flaps, and to the top edges of bottom flaps.
With this the box itself is finished.
There is room for optimization, and for some extra features, of course. For example, we can easily remove the flute level from the side panels as it’s never visible anyway. Let me also quickly describe how to add zooming buttons and a side image to our gorgeous box.
Zooming
The default behaviour of OrbitControls is zooming the scene by scroll. It means that our scroll-driven animation is in conflict with it, so we set orbit.enableZoom property to false.
We still can have zooming on the scene by changing the camera.zoom property. We can use the same GSAP animation as before, just note that animating the camera’s property doesn’t automatically update the camera’s projection. According to the documentation, updateProjectionMatrix() must be called after any change of the camera parameters so we have to call it on every frame of the transition:
The image, or even a clickable link, can be added on the box side. It can be done with an additional plane mesh with a texture on it. It should be just moving together with the selected side of the box:
function updatePanelsTransform() {
// ...
// for copyright mesh to be placed on the front length side of the box
copyright.position.copy(box.els.frontHalf.length.side.position);
copyright.position.x += .5 * box.params.length - .5 * box.params.copyrightSize[0];
copyright.position.y -= .5 * (box.params.depth - box.params.copyrightSize[1]);
copyright.position.z += box.params.thickness;
}
As for the texture, we can import an image/video file, or use a canvas element we create programmatically. In the final demo I use a canvas with a transparent background, and two lines of text with an underline. Turning the canvas into a Three.js texture makes me able to map it on the plane:
In recent years, organizations worldwide have started leveraging DevOps to deliver high-quality products at high speed. Every DevOps team is busy automating everything, with constant discussions about continuous integration, continuous delivery, automated deployments, GitOps, and Infrastructure as Code. Though automation has enabled the business to realize some of the benefits of DevOps, the dozens of non-collaborative tools in their DevOps toolchain made the task of automation a technically complex and arduous task. As DevOps automation reached its limitations, DevOps orchestration has emerged as the logical next step of automation. Let's dig deep and learn the ins and outs of DevOps orchestration.
What Is DevOps Orchestration?
DevOps orchestration is the process of automating a set of several independent automated tasks to streamline and optimize the entire DevOps workflow. It is the automated coordination and management of your entire DevOps practices and automation tools you have implemented to accelerate the software development life cycle (SDLC). This significantly minimizes production issues, accelerates time to market, improves the efficiency of your automation tools, and increases the ROI of your DevOps investments. DevOps orchestration includes continuous integration, continuous delivery, continuous deployment, containerization, cloud-based services, monitoring, and analytics.
What is Node.js? Why use Node.js? Let's dig deeper and find out more details to help you decide whether this environment is the right choice for your app development.
Are you developing an app from scratch? Want your app to be fully functional? If so, you need to choose the right tools, platforms, and languages.
When making a list of key skills for an engineer, developers and engineers likely focus heavily on technical proficiencies. Although technical knowledge is necessary to be an engineer, the ability to communicate effectively is too often overlooked.
Why Do Engineers Need Communication Skills?
The answer is simple: Today’s challenges are too big for one individual to tackle alone; they require collaboration across large teams of people with distinct skill sets. This is especially true in transformative projects involving advanced technologies such as artificial intelligence and machine learning. People from different backgrounds communicate in unique ways, and being aware of this can make us more efficient.
I have a website that have 6 videos from +500MB to +1GB i have uploaded them my other hosting which is not same as the website thinking it would not have lag. But it seems it has lag and its loading slow.
What solution do i have to host my videos in mp4 file so i can link them in html5 video tag?
I must link them in html4 video tag because i am hidding the video controls from user and i have made JavaScript buttons for (start & full screen).
Free stock photos have become a huge commodity on the web. They’re easier to find than ever before and it’s quite possible there are millions of these photos to choose from.
These free photos certainly make design work easier, but finding high-quality photos for hero images can be a real pain. That’s why I’ve curated the absolute best sites to help you find HQ photos for all your web design projects.
NegativeSpace
First in this collection is NegativeSpace, featuring a gorgeous high-resolution gallery of stock photos. But these photos don’t have that cheesy vibe you typically expect from stock photo sites.
They all look incredibly natural and they span a wide array of topics. You can find photos to use on a business website, a restaurant homepage, or even pictures to use as featured photos on your personal blog.
Categories are easy to browse through and the layout is incredibly simple. If you need genuine-looking stock photos then start with NegativeSpace.
Gratisography
Gratisography is probably the most unique site in this bunch, with thousands of some of the quirkiest and sometimes even weird free stock photos you can find.
Started by creative Ryan McGuire, these photos are truly one of a kind. Not only won’t you find them anywhere else, they are unlike any others that populate other stock photo sites. They are pretty specific in their uniqueness, so if you’re looking for that perfect fit photo (or vector illustration), you could find it here.
LibreStock
All the photos on LibreStock come from dozens of other sources. This site works like a search engine for CC0 stock photography where you can enter a search term and browse 40+ different sites all at once.
Since many stock photo sites are small, they also don’t have many photos. But the photos they do have are usually unique and not found elsewhere. So LibreStock saves you time searching all these sites at once and curating the results in one place.
This is my go-to resource to search all the smaller sites before visiting the larger ones. They’ve also recently launched a free video search engine as well.
Picography
Next on the list is Picography, with a constant stream of new photos added every day. Not only are many of these photos unique to this site, but there are thousands to choose from and more to come.
This site is easy to search so you can find just the right photo for your needs and you’re not likely to see it being used anywhere else.
StockSnap
With StockSnap you can actually make your own account and curate all your favorite photos together.
All StockSnap photos are CC0 and they’re certainly large enough for hero images. And since you can bookmark your favorites you have easy access to find the original photographer, the tags, and even related photos based on size/color and content.
Stockvault
Stockvault has been around awhile, and that means it has, well, a literal vault full of thousands of free stock photos available for download. Search the vast collection and you will find a wide variety of pics for whatever you need.
Startup Stock
Tech blogs and startups thrive on great photography. That’s why Startup Stock Photos has to be in this list.
It’s a fairly new website but the quality is exquisite. I haven’t seen these photos anywhere else so they must be uniquely featured here with the goal of helping writers & startup founders add quality images to their site.
You can read a bit more about the site in this post written by one of the creators.
ShotStash
ShotStash is a bit of a “boutique” type of stock photo site, aimed at “creative professionals”. With a smaller but more specific selection you should be able to find some solid unique options here.
ISO Republic
ISO Republic has a great mix of free stock photos and videos with a variety of subjects, including business, technology, food, and many others. One really nice feature is being able to narrow your search to videos only, if that’s what you’re looking for. All of their content is under CC0 license so you can download, edit, and reuse them on any projects. Awesome!
Foodie Factor
If you’re looking for high quality and unique images of delicious food beyond today’s Instagram fare, Foodie Factor is a great resource to bookmark. It’s a very specific niche, but this recently relaunched site has beautiful photos of wonderful dishes that will add mouth-watering depictions to your projects. Check it whenever you’re looking for food-related free stock photos, as they are adding new photos all the time.
These are my favorite hero image resources but there are many others, like Free Nature Stock that you might like to try. CC0 images are so commonplace that it’s tough to even keep up with all the photos!
But if you keep some of these sites bookmarked you’ll have access to the vast majority of new images right at your fingertips.
TikTok is one of the fastest-growing social media platforms. With millions of active users, you can now use it to engage with online users willing to support your brand. Although it’s a social media app,...
