So instead of asking “why not React?” we asked: Which of our actual problems would React solve? We went through the list. There were none.
Also, this is good advice when you’re about to make a web component:
Every component starts with the question “does a semantic element already exist for this?”, and remarkably often the answer is yes.
A history of front-end development that culminates here:
The frontier of 2026, the stuff the sharpest people are most excited about, is render the HTML on the server, ship almost no JavaScript, and use the web platform instead of fighting it.
Alex takes issue with my post giving kudos to Apple for concentrating on bugfixes in the latest version of Safari, and he brings receipts. He makes a very compelling case, backed up with data.
But when it comes to Chrome’s shipping of the half-baked prompt API, I’m not sure he gets just how badly it has soured the developer community’s feelings towards Google. This isn’t something to be countered with data; it’s much more visceral than that. Alex says:
So if Jeremy has a problem with specific features, I hope he’ll come to us with a critique of their qualities, rather than their optics.
In this case though, the optics are really, really, really bad.
This is excellent advice and I’m glad to see this getting addressed nice and early in the era of customisable select elements:
always provide text content or accessible text attributes for your option elements.
CSS Grid Lanes has started to ship in browsers. It’s in Safari and behind a flag in Chrome and Edge.
It enables masonry layouts, where items get packed together in the most efficient way possible.
Unsurprisingly, I’m a fan of a layout tool where the browser does all the hard work. It very much aligns with the idea of declarative design; you specify the boundary conditions, and then browser does the maths and heavy lifting.
There’s a handy website called The Field Guide to Grid Lanes where you can play around with possibilities.
At the most recent CSS Day, Patrick Brosset gave a great talk showing what you could do with Grid Lanes. I immediately started playing around with it, and I spotted what I think could be a useful pattern…
Over on The Session, I added a little enhancement to the events and sessions listings recently. I make a call to the Google Places API to see if I can find a match for the venue, and if I do, pull in some photos.
Sidenote: right now there’s a major issue with this. None of the photos come with text descriptions. This is something I need to fix, and I’ve got some ideas on how to do that.
Anyway, these photos are just nice-to-haves so I’ve tucked them away into a details element with a simple summary like “Ten photos” or “Twenty photos”. If you open up that details element you get the photos in a horizontal swipable row. A carousel, if you will.
This works fine, but on larger screens I think it would be okay to show all the photos at once. That’s where Grid Lanes comes in.
Take a look at an event or a session in Safari to see what I mean.
Here’s the CSS that creates a carousel:
.gallery {
display: flex;
align-items: center;
inline-size: fit-content;
max-inline-size: 100%;
overflow-inline: auto;
scroll-snap-type: inline mandatory;
overscroll-behavior-inline: contain;
scroll-behavior: smooth;
scrollbar-gutter: stable;
}
.gallery > * {
flex-shrink: 0;
scroll-snap-align: center;
}
And here’s the media query that turns it into a masonry layout:
@supports (display: grid-lanes) {
@media all and (min-width: 56em) {
.gallery {
all: initial;
display: grid-lanes;
grid-template-columns: repeat(auto-fill, minmax(280px, 1fr));
gap: 0.5em;
}
.gallery > * {
inline-size: 100%;
}
}
}
I’m using all: initial to unset the previous styles, which is a bit of a sledgehammer but it works.
I think this could be a useful responsive design pattern. Masonry layouts are great for large screens but kind of rubbish for small screens where you end up with just a single column. Carousels aren’t much cop on large screens but maybe have their place on small screens where real estate is at a premium.
Oh, and needless to say, this is a progressive enhancement. If a browser doesn’t yet understand display: grid-lanes it continues to get the carousel layout.
I give Apple a hard time. That’s mostly due to how they treat the web on their own mobile devices.
Though iOS ostensibly supports the ability for websites to be added to the homescreen, they make it so difficult for users to do, the functionality is practically worthless. It’s dispiriting to see the web so hamstrung by that decision.
The Webkit team has come in for other criticism too. For a while there, Safari was lagging so far behind in features that people were calling it the new Internet Explorer. Ouch!
But credit where credit is due. The upcoming version 27 of Safari is looking very good.
That’s not because it’s at the cutting edge of the latest web standards. Quite the opposite. Most of the changes listed for this release are bug fixes. That’s what I want to acknowledge and applaud.
Far too often a browser will rush out an implementation of an exciting new web standard that gets plenty of attention. But that initial implementation is rarely 100% correct. Then the next release rolls around and the focus has moved on to a different new web standard. The result is an ever-growing backlog of almost-but-not-quite-supported features.
Clearly the focus for Safari 27 was on that backlog. I bet that wasn’t an easy decision. Like I said, the kudos and recognition tends to go to the browser that ships new stuff, not the browser that goes back to fix long-standing issues.
Don’t get me wrong, there’s some exciting new stuff in Safari 27 too, like styleable select, but it’s great to see the focus on maintenance and repair:
If you look through the lists of features and fixes in Safari 27, you’ll notice that, although there are 58 brand-new features and 525 fixes — the largest pile of fixes in any Safari release in recent memory — most of what is released is not about new things.
Most of this work has been about existing features behaving more correctly, handling more edge cases, and fitting together with other features the way you’d expect.
This in sharp contrast to the most recent release of Chrome that shipped support for the prompt API despite opposition from other browsers and no positive signals from developers. I hope some Googler got a nice promotion for shoving a proprietary technology into a web browser, but they should be aware of the damage they’ve done.
At this year’s CSS Day, the represenatatives from Google Chrome were once again there to talk to developers and ask what we wanted them to prioritise. Those requests rang very hollow. Why should we waste our time and energy telling a browser team what we need if they’re just going to ship whatever crap they want?
The truth is that the folks from Google who were canvassing opinions from the attendees at CSS Day are not the same people who torpedoed the browser with unwanted proprietary tech. This team has spent years doing excellent outreach, documenting web standards, and meeting with developers. They built up an impressive amount of trust, respect, and goodwill.
That stock has now plummeted.
So well done to the Webkit team for Safari 27. And shame on the Chrome team for Chrome 148.
The browser is the security boundary. Websites operate within it. Native apps bypass it.
But there’s still one thing that native apps do better than the web. If you want to be able to monitor and track users to an invasive degree, the web can’t compete with the capabilities of native apps. That’s why you’ll see so many websites on your mobile device that implore to install their app from the app store.
This piece goes into the details:
Most native apps collect far more data than their website equivalents ever could. They request permissions to hardware, sensors, and background processes that browsers deliberately restrict. The third-party software embedded in these apps frequently transmits your location, device identifiers, and behavioral data to third parties before you even see a consent prompt.
Handy! I’ve added this header to The Session.
Fixed an issue on iOS and iPadOS where
datalistsuggestions were presented directly over the associated input, obscuring it.
No web standard should require you to agree to an advertising company’s “terms of use.”
I’m genuinely disheartened and angry that the Google Chrome team have done this. Never assume good faith from them again.
This is, hands-down, the most insultingly transparent attempt at web standards bullying I’ve ever seen, including past ones from Google, which is — and I cannot stress this point enough — a company that sells advertisements. This is miles more eyeroll-worthy than AMP, where you’ll recall that a legion of tight-smiling dorks wearing Alphabet lanyards tried to assure us that the only means of survival for the web itself was to funnel all of it through Google’s servers, and only use their very good advertisements instead of those bad other ones.
Hallelujah! Support for sizes="auto" is finally landing in Firefox and Safari! Praise be!
This is such a brilliant idea! Why not allow an img element inside video element in order to provide a responsive, accessible poster image?
A stack is also technical debt, non-transferable knowledge, accelerated obsolescence, and vendor lock-in. That means fragility and overall unnecessary complication. Popular stacks inevitably turn into cargo cults that build in spite of the web, not for it.
The web platform does not require build toolchains. Always default to, and regress to, the fundamentals of CSS, HTML, and JavaScript. Those core standards are the web stack.
This was another fantastic conference from the Clearleft team, and one that I hope is repeated next year. It is absolutely incredible what you can do in the browser these days, and even though I thought I was keeping up with the latest developments, it astounded me how far things have come.
Four years ago I wrote about something that has long puzzled me in the world of front-end development. Trust:
The mindset I’ve noticed is that many developers are suspicious of browser features but trusting of third-party libraries.
Developers are more likely to trust, say, Bootstrap than they are to trust CSS grid or custom properties. Developers are more likely to trust React than they are to trust web components.
That post got some thoughtful responses but I never really understood the imbalance of trust and suspicion:
I’m kind of confused by this prevalent mindset of trusting third-party code more than built-in browser features.
But something happened recently that helped me understand that mindset better.
I wrote a while back about how the datalist element on iOS has been completely fucked up. It’s worse than if Safari simply didn’t support it.
Breaking the web like that should be a five-alarm fire, but nobody is in any rush to fix it. I recall a similar lackadaisical attitude when Safari completely broke their implentation of IndexedDB.
I had it in my head that browser features followed a forward path generally. They’d be iterated on and improved on to iron out any glitches, but it was reasonable to expect things to get better with each new version of a browser.
Now I see that’s not necessarily the case.
Had I used an over-engineered JavaScript library instead of the datalist element, I wouldn’t be facing the current situation of having to use browser-sniffing to avoid sending a standard HTML element to any browser on iOS.
Sure, that third-party JavaScript would mean that users are downloading more code, and it probably wouldn’t work well with assistive technology, but as long as I didn’t touch it, it would continue to work. That should be true of web standards—I should be able to use them secure in the knowledge that they won’t suddenly shit the bed.
Perhaps I should be grateful to Apple for dispelling my naïveté. I now have much more empathy and understanding for web developers who are suspicious of web standards and prefer to use third-party libraries instead.
Good job, Apple. Happy anniversary.
Never forget:
- The time Apple lied to the UK regulator
- The time when Apple told the EU that Safari is 3 different browsers
- When Apple tried to shut the UK investigation down
- When Apple’s VP of Finance got caught lying under oath
- When Apple tried to wreck all EU Web Apps
Web development follows a familiar cycle. First we glue together a solution with whatever we have — JavaScript, image hacks, Flash, anything. Then the platform matures, and CSS or HTML eventually makes that same workaround native. Rounded corners, custom fonts, smooth scrolling, sticky positioning: all of these started as JavaScript-heavy hacks before CSS turned them into a single declaration.
We are in another one of those transition moments. A new wave of long-requested CSS features is finally landing, and many of them are explicitly designed to replace patterns that used to require JavaScript. Not as approximations — as first-class platform primitives that handle the edge cases, run in the right thread, and need zero dependencies.
A lovely post from Remy about State Of The Browser and Web Day Out.
On March 12th, 1989, Tim Berners-Lee submitted Information Management: A Proposal. This would form the basis of what became the World Wide Web.
On March 12th, 2026, Web Day Out happened in Brighton.
Coincidence?
Yes. Yes, it is a coincidence. But it’s a pretty nice coincidence, you must admit.
It was a day dedicated to the World Wide Web. Not just the foundational languages of the web—HTML, CSS, and JavaScript—but also the foundational ideas of the web.
“Share what you know!” That was the original motto of the World Wide Web project. That was the motto of Web Day Out too.
Look, I’m biased because I put the line-up together but honestly, all of the speakers were superb! So much knowledge delivered in such entertaining fashion.
I had a blast. And I’ll give myself a little pat on the back for how I grouped the talks into rhyming couplets:
Browsers: Jemima talked about what you can do with just HTML and CSS these days, and Rachel followed up with how to come up with your own browser support strategy.
Performance: Aleth made the case for multi-page progressive web apps that work under any network conditions, and Harry followed up with an impassioned rant about how much time and energy has been wasted on over-engineered single-page apps that ignore what browsers can do.
Styling: Manuel walked us through a whole new approach to writing modern CSS, and Rich followed up with a whirlwind tour of all the great typographic possibilities in CSS.
Standards Jake took us on the standards journey to customisable select elements, including anchor positioning and popovers, and then Lola showed us exactly what it takes to add a new feature to a web browser.
Everything flowed together really nicely.
I was a little apprehensive going into Web Day Out that it would just be preaching to the converted. And sure, there were plenty of veteran devs there who already knew the value of progressive enhancement and making the most of web standards. But I was gratified to also see lots of younger faces in the crowd.
I was talking to one young developer afterwards and she told me what an eye-opening experience it was. Whereas before she would have defaulted to a framework-driven single-page app for everything, now she’s got the knowledge to make an appropriate architectural choice.
Mission accomplished!
If you couldn’t make it to Web Day Out and you want to experience some RAMO, here’s the chatter on Bluesky and Mastodon, lovely photos by Marc, a post by Dave, and a lovely post by Amber.
Thank you so much to everyone who came. I think you’ll agree it was a most excellent day out.