Oh hey! A brand new property that affects how a box is sized! That’s a big deal. There are lots of ways already to make an aspect-ratio sized box (and I’d say this custom properties based solution is the best), but none of them are particularly intuitive and certainly not as straightforward as declaring a single property.
So, with the impending arrival of aspect-ratio (MDN, and not to be confused with the media query version), I thought I’d take a look at how it works and try to wrap my mind around it.
Shout out to Una where I first saw this and boy howdy did it strike interest in folks. Here’s me playing around a little.
Just dropping aspect-ratio on an element alone will calculate a height based on the auto width.
Without setting a width, an element will still have a natural auto width. So the height can be calculated from the Aspect ratio and the rendered width.
If the content breaks out of the Aspect ratio, the element will still expand.
The Aspect ratio becomes ignored in that situation, which is actually nice. That’s why the pseudo-element tactic for Aspect ratios was popular, because it didn’t put us in dangerous data loss or awkward overlap territory when content got too much.
But if you want to constrain the height to the Aspect ratio, you can by adding a min-height: 0;:
If the element has both a height and width, aspect-ratio is ignored.
The combination of an explicit height and width is “stronger” than the Aspect ratio.
Factoring in min-* and max-*
There is always a little tension between width, min-width, and max-width (or the height versions). One of them always “wins.” It’s generally pretty intuitive.
If you set width: 100px; and min-width: 200px; then min-width will win. So, min-width is either ignored because you’re already over it, or wins. Same deal with max-width: if you set width: 100px; and max-width: 50px; then max-width will win. So, max-width is either ignored because you’re already under it, or wins.
It looks like that general intuitiveness carries on here: the min-* and max-* properties will either win or are irrelevant. And if they win, they break the aspect-ratio.
.el {
aspect-ratio: 1 / 4;
height: 500px;
/* Ignored, because width is calculated to be 125px */
/* min-width: 100px; */
/* Wins, making the Aspect ratio 1 / 2 */
/* min-width: 250px; */
}
With value functions
Aspect ratios are always most useful in fluid situations, or anytime you essentially don’t know one of the dimensions ahead of time. But even when you don’t know, you’re often putting constraints on things. Say 50% wide is cool, but you only want it to shrink as far as 200px. You might do width: max(50%, 200px);. Or constrain on both sides with clamp(200px, 50%, 400px);.
But say you run into that minimum 200px, and then apply a min-width of 300px? The min-width wins. It’s still intuitive, but it gets brain-bending because of how many properties, functions, and values can be involved.
Maybe it’s helpful to think of aspect-ratio as the weakest way to size an element?
It will never beat any other sizing information out, but it will always do its sizing if there is no other information available for that dimension.
It’s probably one part coronavirus, one part new-fancy-video setup, and one part “hey this is good for CodePen too,” but I’ve been doing more videos lately. It’s nice to be back in the swing of that for a minute. There’s something fun about coming back to an old familiar workflow.
Where do the videos get published? I’m a publish-on-your-own site kinda guy, as I’m sure you know, so there is a whole Videos section of this site where every video we’ve ever published lives. There is also a YouTube channel, of course, which is probably the most practical way for most people to subscribe. We’re about halfway to Wes Bos-level, so let’s go people!
I had literally forgotten about it, but ages ago when I set this up, I created a special RSS feed for the videos so I could submit it as a video podcast on iTunes. That’s all still there and working! An interesting side note is that this enables offline viewing, as most podcatchers can cache subscriptions. Why build an app when you get the core ability for free, right?
I keep the original videos, of course. On individual video pages, I show a YouTube player that could be somewhat easily swapped out for another player if something crazy happened, like YouTube closes down or drastically changed their business model in some way that makes it problematic to show videos with their player. The originals are stored in an S3 bucket. If you’re an MVP Supporter, I give you the original high-quality download link right on the video pages.
If your curious about my workflow, I’m still using ScreenFlow. I don’t make nearly enough use of it, but it feels good in that it’s fairly easy to use, very reliable and fast, and I can always learn and do more with it. Shooting my screen is easy and a built-in feature of ScreenFlow of course. I also have a Rode Podcaster on a boom arm at my desk so the audio is passable. And I just went through a whole process to use a DSLR camera at my desk too, and I think the quality from that is great. It’s all a little funny because I have this whole sound recording booth as well, with a $1,000 audio setup in there, but I only use that for podcasting. The lighting sucks in there, making it no good for video.
It’s this new desk setup that has inspired me to do more video, and I suspect it will continue! One thing I could really use is a new high quality intro video. Just like a five-second thing with refreshed aesthetics. Anyone do that kind of work?
There’s some new units I was totally unaware of from the Level 4 spec for CSS values! The lh unit is “equal to the computed value of line-height” and rlh is the same only of the root element (probably the <html> element) rather than the current element.
I linked up Water.css not long ago as an interesting sort of CSS framework. No classes. No <h2 class="is-title">. You just use semantic HTML and get styles. Is that going to “scale” very far? Probably not, but it sure is handy for styling things quickly, where — of course — you’re writing semantic HTML but don’t need to care tremendously about the look, other than it should look as decent as it can with low effort.
This week I saw MVP.css making the rounds. Same idea. There are a bunch more!
Chase McCoy wrote a nifty post about the “gap problem” when making a grid of items. His argument might be summarized like this: how should we space elements with margins in CSS? He notes that the gap property isn’t quite ready for prime time when it comes to using it with flexbox, like this:
.grid {
display: flex;
gap: 10px;
}
Right now, using gap with flexbox is only supported in Firefox and I’ve already caught myself forgetting about that in a few projects. So watch out for that.
Make a grid with a 10px gap between each column and row.
Each column should have a minimum width (150px).
Each column should also be equal width (1fr).
The grid should auto-fill as many columns that can fit.
The nifty thing about all this is that our grid is now effectively responsive because of minmax — if you resize the browser, then the grid will snap down into fewer columns, just like this:
No media queries at all! Although sure, there’s a few other ways that you could get this to work but I think this is neat not just because we’re avoiding media queries — instead, it’s because it teaches us to think in a new way when designing and building components.
Chase continues:
With this technique, instead of using breakpoints to specify the screen size where your items should stack, you specify the minimum size an element should be before it stacks. I like this because it encourages developers to think about responsive design in terms of behaviors instead of screen sizes.
“Behaviors instead of screen sizes” is such a great way to think about component design! A lot of the problems I’ve encountered when making components for a design system is when I’ve been thinking about screen sizes — mobile, tablet, desktop, etc. — and trying to make those components fit within those constraints.
Thinking in behaviors is always more effective because there are so many things that can impact a component beyond what screen or device width we’re working with. Perhaps we want that component to fit inside another component. Or we want to align some helper text to the side of it for comparison.
Either way, thinking about behaviors instead of screen sizes isn’t really going to be fully impossible until we have container queries, as Chris writes:
Container queries are always on the top of the list of requested improvements to CSS. The general sentiment is that if we had container queries, we wouldn’t write as many global media queries based on page size. That’s because we’re actually trying to control a more scoped container, and the only reason we use media queries for that now is because it’s the best tool we have in CSS. I absolutely believe that.
Foldable phones are starting to be a thing. Early days, for sure, but some are already shipping, and they definitely have web browsers on them. Stands to reason that, as web designers, we are going to want to know where that fold is so we can design screens that fit onto the top half and bottom half… or left half and right half¹.
Looks like that’s going to make its way to us in the form of env() constants, just like all that notch stuff.
Interesting how there is no fold-right, isn’t it? And aren’t we trying to stay away from directional terms like that and use logical properties? Why not fold-inline-start?
It’ll be interesting to see how that sentence ages. Just watch the first really popular foldable phone will have three segments.
Justin Duke asks if treating code comments like footnotes could help us understand the code in a file better. In his mockup, all the comments are hidden by default and require a click to reveal:
What a neat idea! Justin’s design reminds me of the way that Instapaper treated inline footnotes.
Instapaper (circa 2012)
I guess the reason I like this idea so much is that a lot of comments don’t need to be read constantly, — they’re sort of a reminder that, “Hey, this needs work in the future” or “Yikes, this is weird and I’m sorry.” Keeping these comments out of the code makes it much easier to scan the whole file, too.
I do wonder if there could be a toggle that shows every comment, just in case you need to read all the comments in sequence rather than clicking to toggle each one.
Anyway, all this talk about comments reminds me of an absolutely fantastic talk by Sarah Drasner at JSConf this year where she discussed why comments are so dang hard to get right:
The other day, I realized that web performance is an enormous topic covering so very much — from minimizing assets to using certain file formats, it can be an awful lot to keep in mind while building a website. It’s certainly far too much for me to remember!
So I made a web performance checklist. It’s a Notion doc that I can fork and use to mark completed items whenever I start a new project. It also contains a bunch of links for references.
This doc is still a work in progress. Any recommendations or links?Feel free to suggest something in the comments below!
Independent transforms happen first. The transform property happens last and stacks on top of what has already been done, which can get confusing¹.
They all share the same transform-origin.
The offset-* properties also effectively moves/rotates elements. Those happen after independent transforms and beforetransform.
Claus Colloseus wrote in to fix some issues in this post and clarify just how confusing this can be. For example, rotate: 45deg; transform: rotate(-45deg); will do nothing as both of them will apply and effectively cancel each other out. So shouldn’t translate: 50px 0; rotate: 45deg; transform: translate(-50px, 0) rotate(-45deg); also all cancel out? No, because of the ordering, the end result is like translate(14.6447px, -35.3553px).
I, Dave Rupert, a person who cares about web performance, a person who reads web performance blogs, a person who spends lots of hours trying to keep up on best practices, a person who co-hosts a weekly podcast about making websites and speak with web performance professionals… somehow goofed and added 33 SECONDS to their page load.
This stuff is hard even when you care a lot. The 33 seconds came from font preloading rather than the one-line wonder of font-display.
I also care about making fast websites, but mine aren't winning any speed awards because I'll take practical and maintainable over peak performance any day. (Sorry, world)
Funny timing on this I was just looking at the website for Utopia (which is a responsive type project which I hate to admit I don't fully understand) and I came across some CSS they show off that looked like this:
See anything weird there? That code is using mathematical operators, but there is no calc() function wrapped around it.
Just as my curiosity set in, Trys Mudford, a creator of Utopia, blogged it:
The value after the : in the CSS custom property does not have to be valid CSS. It won’t cause any errors, nor invalidate the custom property. It won’t be evaluated in the browser until used, or more specifically, placed in a calc() function.
Here's a contrived example:
:root {
--padding: 1rem;
/* These are meaningless alone */
--padding-S: var(--padding) / 2;
--padding-L: var(--padding) * 2;
}
.module--large {
/* But they evaluate once they are in a calc() */
padding: calc(var(--padding-L));
}
In my limited understanding, currying is like functions that return functions. I suppose this is sorta like that in that the alternate padding properties above are sort of like derivative functions of the main padding function (if you can call it that), and you only call them and execute them as needed.
Have you ever clicked on an image on a webpage that opens up a larger version of the image with navigation to view other photos?
Some folks call it a pop-up. Others call it a lightbox. Bootstrap calls it a modal. I mention Bootstrap because I want to use it to make the same sort of thing. So, let’s call it a modal from here on out.
Why Bootstrap? you might ask. Well, a few reasons:
I’m already using Bootstrap on the site where I want this effect, so there’s no additional overhead in terms of loading resources.
I want something where I have complete and easy control over aesthetics. Bootstrap is a clean slate compared to most modal plugins I’ve come across.
The functionality I need is fairly simple. There isn’t much to be gained by coding everything from scratch. I consider the time I save using the Bootstrap framework to be more beneficial than any potential drawbacks.
Here’s where we’ll end up:
Let’s go through that, bit by bit.
Step 1: Create the image gallery grid
Let’s start with the markup for a grid layout of images. We can use Bootstrap’s grid system for that.
Now we need data attributes to make those images interactive. Bootstrap looks at data attributes to figure out which elements should be interactive and what they should do. In this case, we’ll be creating interactions that open the modal component and allow scrolling through the images using the carousel component.
About those data attributes:
We’ll add data-toggle="modal" and data-target="#exampleModal" to the parent element (#gallery). This makes it so clicking anything in the gallery opens the modal. We should also add the data-target value (#exampleModal) as the ID of the modal itself, but we’ll do that once we get to the modal markup.
Let’s add data-target="#carouselExample" and a data-slide-to attribute to each image. We could add those to the image wrappers instead, but we’ll go with the images in this post. Later on, we’ll want to use the data-target value (#carouselExample) as the ID for the carousel, so note that for when we get there. The values for data-slide-to are based on the order of the images.
This is a carousel inside a modal, both of which are standard Bootstrap components. We’re just nesting one inside the other here. Pretty much a straight copy-and-paste job from the Bootstrap documentation.
Here’s some important parts to watch for though:
The modal ID should match the data-target of the gallery element.
The carousel ID should match the data-target of the images in the gallery.
The carousel slides should match the gallery images and must be in the same order.
Here’s the markup for the modal with our attributes in place:
Looks like a lot of code, right? Again, it’s basically straight from the Bootstrap docs, only with our attributes and images.
Step 3: Deal with image sizes
This isn’t necessary, but if the images in the carousel have different dimensions, we can crop them with CSS to keep things consistent. Note that we're using Sass here.
You may have noticed that the markup uses the same image files in the gallery as we do in the modal. That doesn’t need to be the case. In fact, it’s a better idea to use smaller, more performant versions of the images for the gallery. We’re going to be blowing up the images to their full size version anyway in the modal, so there’s no need to have the best quality up front.
The good thing about Bootstrap’s approach here is that we can use different images in the gallery than we do in the modal. They’re not mutually exclusive where they have to point to the same file.
So, for that, I’d suggest updating the gallery markup with lower-quality images:
<div class="row" id="gallery" data-toggle="modal" data-target="#exampleModal">
<div class="col-12 col-sm-6 col-lg-3">
<img class="w-100" src="/image-1-small.jpg" data-target="#carouselExample" data-slide-to="0">
<!-- and so on... -->
</div>
That’s it!
The site where I’m using this has already themed Bootstrap. That means everything is already styled to spec. That said, even if you haven't themed Bootstrap you can still easily add custom styles! With this approach (Bootstrap vs. plugins), customization is painless because you have complete control over the markup and Bootstrap styling is relatively sparse.
One particular pattern [for loading non-critical CSS] I’ve seen is the preload/polyfill pattern. With this approach, you load any stylesheets as preloads instead, and then use their onload events to change them back to a stylesheet once the browser has them ready.
So you're trying to make your stylesheet more async, but it causes two big problems:
You've kicked up the priority of the downloading higher than any other asset.
You've blocked the HTML parser too (because of the polyfill as an inline script).
Firefox does something fancy to avoid problem #2 in this particular case, but it affects every other browser.
I've never had good luck with fancy techniques to trick the browser into theoretically better downloading/rendering patterns. I'm kind of a stylesheets in the head, scripts at the end of the body kinda guy, but I know the web is a complicated place. In fact, in a quick peek, I see that Jetpack is inserting an inline script into my <head>, so that would affect my loading too, except they load it with an obfuscated type until later scripts execute and change it, probably to avoid this exact problem.
Anyway, Tim's advice:
• If you’re using loadCSS with the preload/polyfill pattern, switch to the print stylesheet pattern instead.
• If you have any external stylesheets that you’re loading normally (that is, as a regular stylesheet link), move any and all inline scripts that you can above it in the markup
• Inline your critical CSS for the fastest possible start render times.
When designing a new website, there’s a long list of specifications and requirements you have to fulfill. It’s just the nature of web design these days. And at the top of that list sits responsive web design.
Thankfully, high-quality WordPress themes like BeTheme make it insanely easy to check off all the technical requirements you’re expected to meet — including responsive design. But why does it matter so much?
Well, for starters, more than half of all website traffic takes place on mobile according to data from StatCounter.
While desktop has put up a good fight for a couple years, mobile has prevailed as the winner. It will continue to do so, too, considering how much more convenient it is to access the web from the palm of one’s hand.
Plus, Google has made it clear that it rewards responsive web designs and mobile-friendly websites with better search rankings, so there’s no hiding from it now.
Responsive web design is a must.
Just keep in mind that following the rules for good mobile design doesn’t mean you ignore desktop users. By prioritizing the mobile experience, you can design more beautiful and efficient websites for all users.
Let’s look at some examples that demonstrate how to do this well.
Responsive web designs that encourage leaner desktop experiences
Just because you have more space to work with when designing for desktop users doesn’t mean you need to make the most of every pixel.
In fact, as Internet-enabled devices have grown smaller in size, it’s encouraged many designers to create leaner and more efficient experiences on desktop.
Take the website for designer/developer Rob Grabowski, for example.
This is how his website appears on a mobile screen:
With minimized logo and navigation out of the way, this allows the focus to remain on his photo and welcome message. Desktop visitors encounter the same thing:
This consistency in design is great because it enables visitors to seamlessly transition from viewing a website on one device to another (which happens often).
Mobile web designs that improve the decision-making process
Consumers today struggle with an overabundance of choice. It might be easier to find that thing or service they’re looking for, but that doesn’t make choosing between similar options any easier.
One of the benefits of responsive design is that it forces web designers to create websites in a modular fashion so that, as the screen size shrinks, each section falls in line beneath the others.
In turn, this makes it easier for customers to review options one-by-one. BeRepair, one of the 500+ pre-built sites from BeTheme, demonstrates this point really well:
This is one of the services offered. Notice how the responsive layout allows the visitor to really focus on the details before them and not get distracted by too much information.
This works well for other types of websites. Take, for instance, the BeRestaurant pre-built desktop site:
It’s a great-looking restaurant website. The mobile counterpart looks just as great, but minimizes the distractions so the core elements can really shine:
Rather than try to fit the menu to the right of the food images, the responsive website maintains the integrity of the original design by tucking it into the hamburger menu icon in the top-right.
Again, this is all about giving your visitors the ability to pause and really focus on the key actions you’re asking them to take. A navigation bar in full view would only distract from that.
Responsive designs that cut out the excess
Think about the last time you went to an art gallery or museum and the kinds of paintings you encountered:
The landscape murals that have a central focus but beautiful details surrounding it.
The portraits with a singular focus that’s chock-full of intimate details.
What’s cool about responsive websites is that they allow us to display the same web page in both formats.
Desktop screens thereby display landscape murals and mobile screens display portraits. But it’s important to know where the excess is in the desktop view so you can trim it back enough to make the mobile experience worthwhile.
For instance, this is the desktop site for BeITService:
This is a great looking hero banner on the home page. It’s well-balanced, the colors are carefully chosen, and the message is crystal-clear.
This is a good example of how smart designers have become when it comes to choosing responsive images for websites.
Here’s that same image and banner from above, but now displayed on mobile:
The image may not appear in full, but there’s nothing lost in this translation from desktop to mobile. What’s more, the message remains front and center.
On desktop, it shows an elaborate background graphic that enhances the overall design. On mobile, however, it turns into this:
Even with the image now reduced and placed at the bottom, it’s still a striking design that allows the message to really shine through.
Another great example is BeTutor. This is how the desktop version looks like:
Here we have the main title and some more info using smaller text. In order not to cramp the mobile view, the design omits the extra content and focuses on the primary message:
The mobile view stays uncluttered without loosing any of the important subject matter that reveals the type of service offered.
Responsive websites that leverage their space
While a small screen requires reducing content in most of the cases, some responsive web designs leverage the space and use the different ratio to their advantage.
While the desktop version focuses on their main tagline, the mobile version makes use of the vertical space and shows more content, giving the mobile visitor an option to learn more about the company right away:
So a mobile design don’t necessarily have to show less content in order to work well.
The mobile screen ratio allows for making use of the vertical space, like it’s shown in this example of BeCosmetics. Check out the desktop view:
The mobile view has more vertical space so the introductory content can be shown along with the button that invites the user to explore all products:
Once again, these examples demonstrate that less space doesn’t need to mean less useful content for the mobile website user.
Responsive websites that enhance readability
When laying out text on a desktop website, you have to be careful about how much you show to a reader at once. Put too many words on a line or not include enough spacing between letters, and your visitors might skip reading it altogether.
It’s a tricky balance to maintain and usually requires visual elements to balance out the text. Take, for example, the BeDanceSchool site:
Thanks to the funky designs and eye-catching graphics around the text, it’s easy for visitors to focus on the content and read it all the way through.
This won’t work on mobile though, which is why it’s important to understand the strengths of each screen size. Here you can see how that same text from above should be handled on mobile:
The design is paired back immensely so that all the visitor can see is the content. But that’s okay because the text is still beautifully styled which helps keep attention.
That said, text presented to mobile visitors doesn’t always have to be so heavily styled. If you select the right font size and type, you can create something that’s readable and engaging just as Base Coat does:
Just be mindful of the vertical length of text on mobile. While it might be easy to see where it ends on desktop, it can seem daunting on mobile if it appears to go on and on.
Mobile sites that put a spotlight on visual content
Responsive web designs aren’t just useful for websites with lots of text. Because of the way content responds to smaller screen sizes, visual storytelling elements look great on mobile, too.
Here’s what visitors see on the BeBand website on desktop:
Mobile screens don’t have the ability to play with balance as in the example above, but they do have the ability to shine a spotlight on the images you’ve chosen:
Websites that contain eye-catching images like this one would certainly benefit from responsive web design.
It’s not just static images that this works with either. The Scott Resort, for example, invites first-time visitors to watch a video:
Regardless of what kind of device the visitor is on, the video automatically conforms to the width of the screen.
This is the video on desktop:
And this is the video on mobile:
With a mobile responsive design, you really allow your content to adapt to the device and experience your users want.
Mobile responsive sites that collect more leads
Although more website traffic comes from mobile devices, it’s still quite difficult to get mobile users to convert as much as they do on desktop. That’ll come with time, but we’re not there just yet.
In the meantime, your responsive site needs to be prepared to capture leads whenever it can to improve those conversion rates.
This “Newsletter” section stands out beautifully on the homepage. And because it’s so convenient (e.g. it’s light on text and requires only one field be filled out), it’s likely to get a ton of subscribers.
This is how that same subscriber form appears on mobile:
Again, it’s really well done — and the smaller, dedicated space on mobile might be an even more effective way to catch the attention of potential subscribers.
So, if you can design your responsive site to collect visitors’ email addresses, you’ll empower them to reconnect with your website from their preferred device. As a result, you can increase the number of conversions it gets.
Responsive web designs for the win
When WordPress users go looking for a theme to design their website with, they look for qualities like:
Ease of use
Cost efficiency
Features
Customizability
Overall design quality
It’s easy to take responsive web designs for granted because we see them everywhere, but, the truth is, not every WordPress theme is built with the mobile user in mind.
BeTheme is different. Each of its 500+ pre-built sites comes with mobile responsiveness baked in.
So, when you use BeTheme, you can spend less time stressing over how to make your website look like the responsive designs above and more time getting your new website online and in front of consumers.
Here’s a neat idea from Tim Kadlec. He uses the Modheader extension to toggle custom headers in his browser. It also lets him see when images are too big and need to be optimized in some way. This is a great way to catch issues like this in a local environment because browsers will throw an error and won’t display them at all!
As Tim mentions, the trick is with the Feature Policy header with the oversized-images policy, and he toggles it on like this:
Feature-Policy: oversized-images ‘none’;
Tim writes:
By default, if you provide the browser an image in a format it supports, it will display it. It even helpful scales those images so they look great, even if you’ve provided a massive file. Because of this, it’s not immediately obvious when you’ve provided an image that is larger than the site needs.
The oversized-images policy tells the browser not to allow any images that are more than some predefined factor of their container size. The recommended default threshold is 2x, but you are able to override that if you would like.
I love this idea of using the browser to do linting work for us! I wonder what other ways we could use the browser to place guard rails around our work to prevent future mistakes...
In the video embedded below, Jen Simmons explains how to improve image loading by using width and height attributes. The issue is that there’s a lot of jank when an image is first loaded because an img will naturally have a height of 0 before the image asset has been successfully downloaded by the browser. Then it needs to repaint the page after that which pushes all the content around. I’ve definitely seen this problem a lot on big news websites.
Anyway, Jen is recommending that we should add height and width attributes to images like so:
This is because Firefox & Chrome will now take those values into consideration and remove all the jank before the image has loaded, even when you override those values in CSS with a fluid width and thus unknown height. That means content will always stay in the same position, even if the image hasn’t loaded yet. In the past, I’ve worked on a bunch of projects where I’ve placed images lower down the page simply because I want to prevent this sort of jank. I reckon this fixes that problem quite nicely.
That's "native" CSS nesting in use there as well, assuming we get that at some point and the syntax holds.
There was some feedback that the code is inscrutable. I don't really think so, to me it says:
All these inputs are allowed both to shrink and grow
There is even spacing around all of it
The email input should be three times bigger than the others
If it needs to wrap, fine, wrap.
A great use case for flexbox, which is the right layout mechanism when you aren't trying to be super precise about the size of everything.
There is a blog post (no byline 🤷♂️) with a more longwinded explanation.
This reminds me a lot of Tim Van Damme's Adaptive Photo Layout where photos lay themselves out with flexbox. They don't entirely keep their Aspect ratios, but they mostly do, thanks to literally the flexibility of flexbox.
