There is really no limit to how you can style them. If you don’t like the default focus ring, you can remove that, but make sure to put some kind of styling back.
Here I’ve used a header element for each expandable section, which has a focus state that mimics other interactive elements on the page.
The only browser that doesn’t support this are the Microsoft ones (and Opera Mini which makes sense—it doesn’t really do interactive).
This browser support data is from Caniuse, which has more detail. A number indicates that browser supports the feature at that version and up.
Desktop
Chrome
Firefox
IE
Edge
Safari
12
49
No
79
6
Mobile / Tablet
Android Chrome
Android Firefox
Android
iOS Safari
86
82
4
6.0-6.1
But even then, it’s just like all the sections are opened, so it’s not a huge deal:
Wanna style that default triangle? Strangely enough, the standard way to do that is through the list-style properties. But Blink-based browsers haven’t caught up to that yet, so they have a proprietary way to do it. They can be combined though. Here’s an example of replacing it with an image:
Unfortunately, they don’t turn, and there is no way to animate the default triangle either. One idea might be to target the :focus state and swap backgrounds:
AVIF, the file format based on the AV1 video codec, is the latest addition to the next-gen image formats. Early reports and comparisons show good results compared to JPEG and WebP. However, even if browser support is good, AVIF is still on the bleeding edge in regards to encoding and decoding. Encoding, decoding, settings and parameters has been well discussed elsewhere.
No doubt, AVIF images generate a smaller payload and are nice looking. In this post, we’ll take a closer look at issues to be aware or before you go all in on AVIF.
1. WebP is Better for Thumbnails
One interesting observation is that for small dimension images, WebP will produce lighter payload images than AVIF.
It’s probably possible to explain why, and tune the encoder to address this case. However, that is not an option for most people. Most people would probably rely on an image optimizer like squoosh.app or an image CDN like ImageEngine. The below comparison uses exactly these two alternatives for AVIF conversion.
We see that WebP will generally produce images with a higher file size than AVIF. On larger dimension images, ImageEngine performs significantly better than squoosh.app.
Now, to the interesting observation. On images around 100px × 100px squoosh.app passes ImageEngine on effectiveness, but then also WebP catches up and for a 80px x 80px image. WebP is actually the most effective image measured in file size.
The test performs relatively consistently on different types of images. For this illustration, this image from Picsum is used.
Pixels
Original JPEG (bytes)
Optimized WebP (bytes)
ImageEngine AVIF (bytes)
squoosh.app AVIF (bytes)
50
1,475
598
888
687
80
2,090
1,076
1,234
1,070
110
3,022
1,716
1,592
1,580
150
4,457
2,808
2,153
2,275
170
5,300
3,224
2,450
2,670
230
7,792
4,886
3,189
3,900
290
10,895
6,774
4,056
5,130
2. AVIF Might Not Be the Best for Product Images with High Entropy
Typically, a product page consists of images of the product, and when a user’s mouse hovers over or clicks on the product image, it zooms …
AVIF, the file format based on the AV1 video codec, is the latest addition to the next-gen image formats. Early reports and comparisons show good results compared to JPEG and WebP. However, even if browser support is good, AVIF is still on the bleeding edge in regards to encoding and decoding. Encoding, decoding, settings and parameters has been well discussed elsewhere.
No doubt, AVIF images generate a smaller payload and are nice looking. In this post, we’ll take a closer look at issues to be aware or before you go all in on AVIF.
1. WebP is Better for Thumbnails
One interesting observation is that for small dimension images, WebP will produce lighter payload images than AVIF.
It’s probably possible to explain why, and tune the encoder to address this case. However, that is not an option for most people. Most people would probably rely on an image optimizer like squoosh.app or an image CDN like ImageEngine. The below comparison uses exactly these two alternatives for AVIF conversion.
We see that WebP will generally produce images with a higher file size than AVIF. On larger dimension images, ImageEngine performs significantly better than squoosh.app.
Now, to the interesting observation. On images around 100px × 100px squoosh.app passes ImageEngine on effectiveness, but then also WebP catches up and for a 80px x 80px image. WebP is actually the most effective image measured in file size.
The test performs relatively consistently on different types of images. For this illustration, this image from Picsum is used.
Pixels
Original JPEG (bytes)
Optimized WebP (bytes)
ImageEngine AVIF (bytes)
squoosh.app AVIF (bytes)
50
1,475
598
888
687
80
2,090
1,076
1,234
1,070
110
3,022
1,716
1,592
1,580
150
4,457
2,808
2,153
2,275
170
5,300
3,224
2,450
2,670
230
7,792
4,886
3,189
3,900
290
10,895
6,774
4,056
5,130
2. AVIF Might Not Be the Best for Product Images with High Entropy
Typically, a product page consists of images of the product, and when a user’s mouse hovers over or clicks on the product image, it zooms …
Some really refreshing technological comparison writing from Eric Bailey. Like, ya know, everything in life, we don’t have to hate or love everything. Baby bear thinking, I like to say. There are benefits and drawbacks. Every single bullet point here is well-considered and valid. I really like the first in each section, so I’ll quote those as a taste here:
Tailwind Benefit: “The utility CSS approach creates an API-style approach to thinking about CSS, which helps many developers work with it.”
Tailwind Drawback:“You need to learn Tailwind class names in addition to learning CSS property names to figure out the visual styling you want. Tailwind is reliant on, and will be outlived by CSS, so it is more long-term beneficial to focus on CSS’ capabilities directly.”
BEM Benefit:“BEM will allow you to describe any user interface component you can dream up in a flexible, extensible way. As it is an approach to encapsulate the full range of CSS properties, it will allow you to style things Tailwind simply does not have classes for—think highly art directed experiences.”
BEM Drawback:“BEM runs full-tilt into one of the hardest problems in computer science—naming things. You need to not only describe your component, but also all its constituent parts and their states.”
And remember, these certainly aren’t the only two choices on the block. I covered my thoughts on some other approaches here.
Here are the big categories of rendering websites:
Client: ship a <div id="root"></div> and let a JavaScript template render all of it.
Static: pre-render all the HTML.
Server: let a live server process requests and generate the HTML response.
They are not mutually exclusive.
A website could statically pre-render 75% of it’s pages (say, blog posts), but the other 25% have a server respond to (say, forums).
A website could statically pre-render all the pages, but have a couple of empty <div>s in there that have client-side rendered content in them (e.g. a dynamically generated menu based on the logged-in user).
A website could be primarily server-rendered, but has caching in front of it such that it behaves statically.
A website could render statically, but then “hydrate” itself into an entirely client-rendered site.
A website could be a mix of server and static rendering, but have dynamic parts similar to client-side rendering, but actually happen in an edge function, so it ends up more like server-side rendering.
Next.js is interesting in that it can do all three. Here’s Tim Neutkens in a recent interview:
Next.js allows you to pre-render pages. It creates HTML on a server at build time with static site generation or uses run-time rendering on the server side. Next allows you to do a hybrid of those. Unlike most other frameworks, you are not bound by, oh, I’m going to build my app completely statically generated. Instead, you’re allowed to have some pages be server-side rendered and some pages be statically generated.
In the new release we make it possible to update these statically generated pages without having to run a new build, rebuilding your whole app.
Cool. Love to see that happening at the framework level. Seems like having to go all-in on one rendering style isn’t practical for a lot of sites.
Client rendering is the most flexible, but comes with all these serious downsides like worse performance, worse reliability, more strain on devices, bad SEO, etc. Static pre-rendering is …
my excitement for Core Web Vitals is tempered with a healthy skepticism. I’m not yet convinced that Largest Contentful Paint (LCP), First Input Delay (FID), and Cumulative Layout Shift (CLS) are the right metrics that all sites should be measuring themselves against. I worry that the outsized emphasis placed on Core Web Vitals by including them in SEO scoring will result in developers focusing solely on those three numbers without truly understanding what they mean and, more importantly, what they don’t mean.
Katie is pro-Web Core Vitals because of their correlation with real user experiences, but there is a lot more to think about. If we focus only on these metrics (because we have now an extremely strong incentive to do so) we’re missing out on a lot. They may not be the analytics that matter most to us or that correlate with business goals.
The horse’s mouth says the SEO implications don’t start until May 2021.
I admit I’ve been on the hype train myself a little bit. I like all of Katie’s points but I think I’ll still call it a step forward for web analytics. Robin also mentioned Sentry could do the tracking the other day.
Personally, my beef with core web vitals is that they introduce even more uneccessary initialisms (see, for example, Harry’s recent post where he uses CWV metrics like LCP, FID, and CLS—alongside TTFB and SI—to look at PLPs, PDPs, and SRPs. I mean, WTF?).
I’ve compared SVG and Canvas before. If you’re trying to decide between them, read that. I’d say the #1 difference between them is vector (SVG) versus raster (Canvas). But the #2 difference is how you work with them. SVG is declarative, as in, literal elements that express what they are through attributes and content. Canvas […]
To access this post, you must purchase MVP Supporter.
I like working with styled-components. They allow you write CSS in your JavaScript, keeping your CSS in very close proximity to your JavaScript for a single component. As a front-end developer who loves to dissect a web page and break it down into reusable components, the idea of styled-components brings me joy. The approach is clean and modular and I don’t have to go digging in some gigantic CSS file to see if a class I need already exists. I also don’t have to add a class to that never-ending CSS file and feel guilty for making that already gigantic file even bigger.
However, as I continue down the path of using styled-components, I have started to realize that, while it is great to separate out CSS styles to be specific to singular components, I am starting to repeat myself a lot for the sake of organizing my styles on a per component basis. I’ve been creating new CSS declarations, and thus, new styled-components, for every component, and am seeing a great deal of duplication in my CSS. No, the styled-components aren’t always exactly the same, but two of the three lines of CSS would match two of the three lines of CSS in another component. Do I really need to repeat this code every place I need these styles?
Take flexbox, for example. Flexbox is great for responsive layouts. It will align items a certain way, and with minimal changes, can be tweaked to look good across different screen sizes. So, more often than not, I find myself writing:
display: flex;
flex-direction: row; /* the default; in react native, column is the default */
Almost as often, I found myself writing:
display: flex;
flex-direction: column;
The two code snippets above are fairly common: the first takes all of the child elements and positions them next to each other — from left to right — in a row. The second takes all of the child elements and positions them above and below each other — from top to …
The survey results from the State of CSS aren’t out yet, but they made this landing page that randomly shows you what one person wrote to answer that question. Just clicking the reload button a bunch, I get the sense that the top answers are:
Container Queries
Parent Selectors
Nesting
Something extremely odd that doesn’t really make sense and makes me wonder about people
I think this might be my most popular tweet of all time, but I’m not sure how to verify that these days. I’ll restate this neat little trick here because blogging is cool and fun.
I used to do this a lot while debugging JavaScript:
console.log("myVariable: ", myVariable);
But now I do this because it’s just easier to type quickly:
console.log({ myVariable });
And you don’t miss out on anything in DevTools:
Now that this is a blog post, I can elaborate a smidge…
The output display there (and really, console.log itself) is a DevTools thing, but the syntax isn’t. By using curly brackets in JavaScript, I’m creating an object. I don’t have to assign an object to anything, it can just be.
{
foo: "bar"
}
You see that a lot when passing an object to a function, like myFunction({ config: options });. The “trick” is that when you’re making an object, you can “shorthand” it by providing only a variable, which makes it implied). So like:
const fruit = "apple";
// Shorthand
let x = {
fruit
}
console.log(x);
// Normal way, literally the same exact thing
x = {
"fruit": fruit
}
console.log(x); // identical
When you have a variable and you log it like console.log({ myVariable }); you’re using that shorthand object creation syntax and it gets logged like the object it becomes.
One strike against this idea is that sometimes DevTools chooses to output it as ▶ Object and you have to click to open to see the value. I don’t know what the heuristics are of when it chooses to do that and when it doesn’t. If you don’t like that, or the output format of an object in general, you might prefer the console.table({ myVariable }); format:
