An excellent example of an HTML web component from Eric:
Extend HTML to do things automatically!
He layers on the functionality and styling, considering potential gotchas at every stage. This is resilient web design in action.
So instead of asking yourself, “How can I write code that does what I want?” Consider asking yourself, “Can I write code that ties together things the browser already does to accomplish what I want (or close enough to it)?”
It’s wild what you can do with CSS these days!
Here’s a handy little tool for generating CSS with :has() selectors in order to do quantity queries.
I’m not the only one who’s amazed by how much you can do with just a little CSS these days.
This is a nifty initiative:
This site lets you rank the proposals you care about, giving us data we can use when reviewing which proposals should be taken on for 2026.
For the record, here’s my top ten:
- Cross-document view transitions
- Speculation Rules API
img sizes="auto" loading="lazy"- Customizable/stylable
select- Invoker commands
- Interoperable rendering of HTML
fieldset/legend- Web Share API
- CSS scroll-driven animations
- CSS
accent-colorproperty- CSS
hanging-punctuationproperty
I was messing about with some images on a website recently and while I was happy enough with the arrangement on large screens, I thought it would be better to have the images in a kind of carousel on smaller screens—a swipable gallery.
My old brain immediately thought this would be fairly complicated to do, but actually it’s ludicrously straightforward. Just stick this bit of CSS on the containing element inside a media query (or better yet, a container query):
display: flex;
overflow-x: auto;
That’s it.
Oh, and you can swap out overflow-x for overflow-inline if, like me, you’re a fan of logical properties. But support for that only just landed in Safari so I’d probably wait a little while before removing the old syntax.
Here’s an example using pictures of some of the lovely people who will be speaking at Web Day Out:
While you’re at it, add this:
overscroll-behavior-inline: contain;
Thats prevents the user accidentally triggering a backwards/forwards navigation when they’re swiping.
You could add some more little niceties like this, but you don’t have to:
scroll-snap-type: inline mandatory;
scroll-behavior: smooth;
And maybe this on the individual items:
scroll-snap-align: center;
You could progressively enhance even more with the new pseudo-elements like ::scroll-button() and ::scroll-marker for Chromium browsers.
Apart from that last bit, none of this is particularly new or groundbreaking. But it was a pleasant reminder for me that interactions that used to be complicated to implement are now very straightforward indeed.
Here’s another example that Ana Tudor brought up yesterday:
You have a
sectionwith apon the left & animgon the right. How do you make theimgheight always be determined by thepwith the tiniest bit of CSS? 😼No changing the HTML structure in any way, no pseudos, no background declarations, no JS. Just a tiny bit of #CSS.
Old me would’ve said it can’t be done. But with a little bit of investigating, I found a nice straightforward solution:
section > img {
contain: size;
place-self: stretch;
object-fit: cover;
}
That’ll work whether the section has its display set to flex or grid.
There’s something very, very satisfying in finding a simple solution to something you thought would be complicated.
Honestly, I feel like web developers are constantly being gaslit into thinking that complex over-engineered solutions are the only option. When the discourse is being dominated by people invested in frameworks and libraries, all our default thinking will involve frameworks and libraries. That’s not good for users, and I don’t think it’s good for us either.
Of course, the trick is knowing that the simpler solution exists. The information probably isn’t going to fall in your lap—especially when the discourse is dominated by overly-complex JavaScript.
So get yourself a ticket for Web Day Out. It’s on Thursday, March 12th, 2026 right here in Brighton.
I guarantee you’ll hear about some magnificent techniques that will allow you to rip out plenty of complex code in favour of letting the browser do the work.
Here’s a comprehensive round-up of new CSS that you can use right now—you can expect to see some of this in action at Web Day Out!
I’ve added this handy little bit of CSS to my starting styles.
Every one of these five proposals is worth a vote.
Mind you, Rich’s cynicism is understandable.
Half of the line-up of speakers for Web Day Out is already on the site. One more is already confirmed.
I’m ridiculously excited about the way the line-up is taking shape, and judging by the zippiness of ticket sales, so are lots of my peers. Seriously, don’t wait to get your ticket or you might end up missing out completely.
I’ve already got a shortlist of other people I could imagine on the line-up, but I’m open to more suggestions. If you’d like to speak at Web Day Out—or you know someone you think would be great—send an email to jeremy@clearleft.com
I won’t be checking my work email while I’m away on holiday next week but it would be lovely to come back to an inbox of exciting suggestions.
A couple of pointers…
I’d rather not have too many people like me on the line-up. White dudes are already over-represented in this industry, especially at conferences.
If you’ve never given a talk before, don’t worry. I’d love to help you put your talk together and coach you in presenting it. I have some experience in this area.
No product pitches. That includes JavaScript frameworks and CSS libraries.
If I get even a whiff of “AI”, your proposal doesn’t stand a chance. There are many, many, many other events that are only too happy to have wall-to-wall talks about …that sort of thing.
If you end up speaking at Web Day Out you will, of course, be paid. We will, of course, cover travel and accommodation too. We can’t afford the travel costs of bringing anyone in from outside Europe though (and we’d like to keep the carbon footprint of the event as small as possible).
Web Day Out has an opinionated agenda all about showing what’s possible in web browsers today. Some potential topics include:
The emphasis should be on using stuff in production rather than theoretical demos.
If you’ve got a case study about using the web platform—perhaps migrating away from a framework-driven approach—that would fit the bill perfectly.
How’s all that sounding? Know someone who could deliver the goods? Let me know!
I’m going to cut right to the chase: Clearleft is putting on a brand new conference in 2026. It’s called Web Day Out. It’ll be on Thursday, March 12th right here in Brighton. Tickets are just £225+VAT. You should be there!
If you’ve ever been to Responsive Day Out or Patterns Day, the format will be familiar to you. There’s going to be eight 30 minute talks. Bam! Bam! Bam!
Like those other one-day conferences, this one has a laser-sharp focus.
Web Day Out is all about what you can do in web browsers today. You can expect talks that showcase hands-on practical uses for the latest advances in HTML, CSS, and JavaScript APIs. There will be no talks about libraries, frameworks or build tools, and I can guarantee there will be absolutely no so-called “AI”.
As you might have gathered, this is an opinionated conference.
If you care about performance, accessibility, and progressive enhancement, Web Day Out is the event for you.
Or if you’ve been living in React-land but starting to feel that maybe you’re missing out on what’s been shipping in web browsers, Web Day Out is the event for you too. And I’m not talking about cute demos here. This is very much about shipping to production.
I’ve got half of the line-up assembled already:
Jemima’s talk gives you a flavour of what to expect at Web Day Out:
In this talk, we’ll take a look at how to use HTML and CSS to build simpler alternatives to popular JavaScript components such as accordions, modals, scroll transitions, carousels etc We’ll also take a look at the performance and accessibility benefits and real-life applications and use-cases of these components.
Web Day Out will be in The Studio Theatre of the Brighton Dome, which is a fantastic intimate venue. That means that places are limited, so get your ticket now!
There’s really good browser support for display-mode media queries and this article does a really good job of running through some of the use cases for your progressive web app.
Put the kettle on. This is a long one!
Matt takes a trip down memory lane and looks at all the frontend tools, technologies, and techniques that have come and gone over the years.
But this isn’t about nostalgia (although it does make you appreciate how far we’ve come). He’s looking at whether anything from the past is worth keeping today.
Studying past best practices and legacy systems is crucial for understanding the evolution of technology and making informed decisions today.
There’s only one technique that makes the cut:
After discussing countless legacy approaches and techniques best left in the past, you’ve finally arrived at a truly timeless and Incredibly important methodology.
I was thinking about something I wrote yesterday when I was talking about styling underlines on links:
For a start, you can adjust the distance of the underline from the text using
text-underline-offset. If you’re using a generous line-height, use a generous distance here too.
For some reason, I completely forgot that we’ve got a line-height unit in CSS now: lh. So if you want to make the distance of your underline proportional to the line height of the text that the link is part of, it’s easy-peasy:
text-underline-offset: 0.15lh;
The greater the line height, the greater the distance between the link text and its underline.
I think this one is going into my collection of CSS snippets I use on almost every project.
We shouldn’t rely on colour alone to indicate that something is interactive.
Take links, for example. Sure, you can give them a different colour to the surrounding text, but you shouldn’t stop there. Make sure there’s something else that distinguishes them. You could make them bold. Or you could stick with the well-understood convention of underlying links.
This is where some designers bristle. If there are a lot of links on a page, it could look awfully cluttered with underlines. That’s why some designers would rather remove the underline completely.
I’ve done a lot of audits in the first half of this year and at this point a believe that designing links without underlines is a kink. The idea that users don’t understand that links are clickable arouses some designers. I can’t explain it any other way.
But underlining links isn’t the binary decision it once was. You can use CSS to style those underlines just as you’d style any other part of your design language.
Here’s a regular underlined link.
For a start, you can adjust the distance of the underline from the text using text-underline-offset. If you’re using a generous line-height, use a generous distance here too.
Here’s a link with an offset underline.
If you’d rather have a thinner or thicker underline, use text-decoration-thickness.
Here’s a link with a thin underline.
The colour of the underline and the colour of the link don’t need to be the same. Use text-decoration-color to make them completely different colours or make the underline a lighter shade of the link colour.
Here’s a link with a translucent underline.
That’s quite a difference with just a few CSS declarations:
text-underline-offset: 0.2em;
text-decoration-thickness: 1px;
text-decoration-color: oklch(from currentColor l c h / 50%);
If that still isn’t subtle enough for you, you could even use text-decoration-style to make the underline dotted or dashed, but that might be a step too far.
Here’s a link with a dotted underline.
Whatever you decide, I hope you’ll see that underlines aren’t the enemy of good design. They’re an opportunity.
You should use underlines to keep your links accessible. But you should also use CSS to make those underlines beautiful.
- Building HTML pages is easy
- Pure HTML is evergreen
- Bloated web pages are too slow
- I can host it anywhere, often for free
- Accessibility and SEO benefits are automatic
- It won’t need security patches
- There are no build steps
SPAs were a clever solution to a temporary limitation. But that limitation no longer exists.
Use modern server rendering. Use actual pages. Animate with CSS. Preload with intent. Ship less JavaScript.
A fantastic explanation of the building blocks of SVG, illustrated—as always—with Josh’s interactive examples.
I don’t normally link to articles on Medium—I respect you too much—and I do wish this were written on Mike Hall’s own site, but this is just too good not to share.
And don’t dismiss this as a nostalgiac case study from the past:
At no point did the constraints make the product feel compromised. Users on modern devices got a smooth experience and instant feedback, while those on older devices got fast, reliable functionality. Users on feature phones got the same core experience without the bells and whistles.
The constraints forced us to solve problems in ways we wouldn’t have considered otherwise. Without those constraints, we could have just thrown bytes at the problem, but with them every feature had to justify itself. Core functionality had to work everywhere, and without JavaScript crutches proper markup became essential.
This experience changed how I approach design problems. Constraints aren’t a straitjacket, keeping us from doing our best work; they are the foundation that makes innovation possible. When you have to work within severe limitations, you find elegant solutions that scale beyond those limitations.