I didn't realize it was tracked like this, but I have noticed that as of iOS 26, Safari has gotten a huge number of great web features. It has WebGPU of course, but many small things like fixing up missing parts of the OPFS API that make it actually usable now. Now they even have the field-sizing CSS property [0], fixing imo the most glaring ommission from CSS: the inability to make text input boxes grow to fit the input text!

[0]: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/P...

This seems like a bit of a trend with Safari. Around big releases Apple will announce how Safari is the best at X, but other times of the year it gets a lot of flack. I assume this is due to Safari’s more traditional release schedule vs other browsers continuously shipping feature updates.

> They surprised us all when they suddenly shot to the top of interop-2025 this October

Not all of us were surprised; some of us have been watching the Safari team shipping the latest HTML and CSS features for a few years now.

Hm, I know that Safari doesn't support 64bit wasm, which is a very important feature that Chrome and Firefox both have, but this seems to say they have "100% webassembly support".

https://webassembly.org/features/

This is not all that surprising. While the Chrome team is out there evangelising things like WebPCIe or whatever, Safari's been shipping features clients actually want, like blurred backgrounds for years before anyone else.

Fascinating tracker. So we started 2025 with nearly every browser under 80% and ending the year with every browser with >98% interop? That's a lot of amazing work done by a lot of teams. Incredible!

My favorite is finally supporting `arbitrary-subdomain.localhost`. Been a real pain in the neck to add Safari-specific fallbacks for my usage of that.

I hope they add WebTransport support soon.

I wonder if Ladybird has explored running these interop tests yet. Or maybe these are just a subset of WPT?

Does it still expand an svg to full size if u omit width and height attributes because u control the size in a parent container? Fuck safari

Safari became the new IE for a while, the amount of problems I've had with Safari CSS animations and SVGs is endless.

It's good they're trying to not make Safari suck as much.

Have you considered using tables?

It is funny how we keep asking more and more and more even though we already have it so much better than before. Can we never be happy with what we have?

Me, too. I like masonry layout too much to wait for CSS to solve the problem, so I've been waiting to remove the last 1.3KB of Javascript from my home page since 2019.

Thank you to everyone who is making this happen.

A lot of web "design" is about how it looks rather than how usable it is. At no point any stakeholder stops and actually uses the product, they scroll up and down, enjoy the pointless "scroll in" animations and say "kewl". Never mind the text that is at 50% opacity until you scroll to the exact intended point, because nobody actually attempted to read it.

The biggest problem is that it's good if your images are all landscape or all portrait, but not when mixed.

Never read a newspaper?

I think this looks great too. Finally replicating the efficiency of newspaper layouts. No enforced symmetry, just content in an optimal space. I want.

I agree, this seems to violate some of the most fundamental concepts of design like least-surprise and using grouping + alignment to give context to readers.

Funny, I think that looks gorgeous!

NYTimes.com comes to mind...

what's your problem?

But if you don't need to systematically examine every element one-by-one, lane layouts are pretty good. Sites like Pintrest use lane layouts because their content isn't meant to by systematically examined, but rather absorbed at a glance. If your content is meant to be systematically examined, using a lane layout would be a bad UX choice. But just because lane layouts can be misused doesn't mean they're a bad layout.

I think it's one of those things that looks good, but is annoying to use non-superficially.

It's not meant to be "efficient," it's meant to allow your eyes to look at the entire page at once to find what you're looking for. A newspaper or photo gallery comes to mind.

Thankfully the feature is just in time for it to fall out of fashion! It really is an awful layout, UX wise. But at least it looks pretty at a glance!

Feels very "right-brain". I'm a brain-hemisphere equality advocate. Good for sites like Pinterest. But also Home Assistant.

This might actually happen indirectly. Kagi’s new browser uses WebKit. macOS only now, but eventually it’ll come to windows

I’m old enough to have installed Safari on Windows XP. I’m not sure it has been enough years since this Apple failed product.

Yeah, there was a years long debate that effectively ended with: “We held a vote that you weren’t aware of and decided that masonry was out. If you cared, you should have participated in the vote that you were not aware was happening. It’s too late to change it.”

https://m.youtube.com/watch?v=yikbSQ6tvlE

I still prefer the layout look from something like justifiedGallery.js where the heights of each row are the same. Actual masonry with stacking stones would never stack directly on top of each other like this. Calling it masonry just feels unnatural as anything stacked like that would easily be knocked over. "Lanes" is definitely more appropriately named than "masonry". The layout look of a justifiedGallery would be more masonry than the grid-template-rows:masonry setting. yeah yeah, raw css vs js library blah blah

iOS used to do this using the Cassowary constraint solver pre-SwiftUI. It’s the worst thing to work with. So much code turning on and off constraints, dynamically adding constraints when you have new views. And that’s before you get into conflicts

Recently discussed on HN: https://news.ycombinator.com/item?id=46144039

I've done that for desktop apps before. You have to be careful with the effects of sub-pixel rendering and whatnot if your math is continuous, but it's a viable path that I quite like.

It's been on-and-off in all three browsers behind flags etc, but it's been in a constant state of flux over the last three years. One of the most gnarly new CSS features to get right. Lots of great arguments about how to implement it.

I have too. And the Safari version that was in the betas/tech previews.

One of the biggest arguments over the last couple of years was what to call it. A lot, lot of ideas put forth as alternatives to "masonry" which wasn't thought to be great for non-English speakers. I'm glad they finally nailed a name for it!

The other big argument was over how to activate it. Is it a grid? Is it a flexbox? Is it a brand new animal?

Now I just need to figure out the best way to implement this semantically with a polyfill for the next 30 months until it's baseline.

They mentioned tabbing and screen readers quite a few times.

I found the "jumping" ordering quite concerning but further down in the article they mention "tolerance" that seems to be a way to allow the layout to be more consistent in terms of ordering.

I guess wire up a codepen demo and try it out. I know the guys writing this were well aware of all the edge cases like that and these are some of the absolute smartest CSS people you can think of who had to write the very detailed spec for this.

I don't think the smooth reflow made it into the current spec, so I guess watch this space?

https://www.w3.org/TR/css-grid-3/

I guess you can just start loading a first batch, add an intersection observer to the last 3 elements (if you have 3 lanes) and then when one of those intersects you simply start fetching the next.

I suppose just checking scroll height of the container? Once you're x pixels above the bottom, fetch more. Not the smoothest, but doable

You just append new <figure> elements to the <main> in the example and it will automatically put them in the appropriate column.

I like Josh W Comeau's content, he has a lot of free articles, but his paid CSS course goes through step by step why CSS is the way that it is, worked great for me for understanding it all. My work paid for it though, that's why it's priced so high, but I'm sure he has discounts for individuals.

This should be a good start: https://nerdy.dev/cascading-secret-sauce

Moving this sort of stuff out of JavaScript and arcane hacks allows the browser rendering engines to optimize these common patterns. This is sorta the opposite of syntactic sugar. The syntactic sugar is the libraries that implemented these patterns without rendering support.

Shall we call it syntactic umami perhaps? Or syntactic lipids?

All these CSS upgrades have been meant to reduce the need for Javascript for all the things web devs do out there in the real world. It's a good thing.

You should tune out more of the ambient cynicism because it's ignorant and unhinged. People who don't follow any standards discussions, don't talk to web devs, don't read anything except headlines and who are only imitating the attitudes of whatever cynical, depressed social media bubble they fell into.

Psh, rocket science only has to contend with physics, which generally doesn't change much, if at all. The equations used to get humans to the moon didn't change because someone discovered you can send a specially crafted packet and escape the sandbox and steal money from everybody on the Internet.

There is no winning, is there? Half of HN wants browsers to revert to document readers and the other half wants HTML and CSS to do what JS can. A small minority then insists that we should get rid of HTML and CSS entirely and start from scratch. The louder the ideas the further away the person is from actually using the tech. I personally would not have the patience for community management.

That said, CSS masonry looks solid.

While I like a Karl Pilkington quote as much as the next guy, I really do want this. I have one specific use case for this layout that's always felt a little bit painful to reach into js for. I can't wait for the day I can simplify that further into native CSS.

How was this masonry layout possible back in the 90s?

I am using a machine older than eleven years old and can still run the newest version of Firefox and Chrome.

I don't think the world needs to cater to people that refuse even basic internet hygiene.

> I use an 11-year-old machine

What OS are you running that can't run modern versions of browsers, and on what hardware?

Current Chrome runs on Windows 10, which came out 9.5 years ago but was intended to run on older computers, and macOS Monterey, which runs on Macs from ~2014-2015 depending on the model. But even Big Sur before that, the most recent version of Chrome which runs on that is Chrome 138 from just 6 months ago, and that doesn't seem old enough that you need to build userscript hacks.

I'm really curious what you're actually running. Generally speaking, an 11-year-old desktop should be able to run the current browser, and if not, a very recent one.

> Personally, I use an 11-year-old machine and have had to add userscript hacks to certain major Web sites to work around bugs in CSS grid (not the "lanes" described here).

The version of CSS Grid we're using today didn't ship until 2017; a browser from 11 years ago would be using one of the non-standard versions of Grid. For example, Internet Explorer 11 was the first browser to ship a grid implementation.

> At least new JavaScript features can be "polyfilled" or whatever. Maybe sites could check for CSS feature support too?

First, not every site needs to look exactly the same in every browser; that's why progressive enhancement is a thing.

Second, there are multiple ways to create masonry-style layouts that don't require masonry support in the browser using multi-column layout or flexbox.

Third, masonry can be polyfilled using JavaScript [1].

[1]: https://masonry.desandro.com/

When the web came out it itself was new technology that excluded some older machines. Lynx kind of worked (I used it!) but it was a poor substitute, especially once `<img>` showed up.

You want to platform to be able to make progress and not be frozen in amber by what we had at some "magical" year when things were in some Golidlocks powerful enough but not too complex state. Especially since a lot of progress lately has been fixing long-standing inconsistencies and obvious gaps.

The cost of that is that yes, neither my Apple IIe or my Micro Pentium 90 run the modern web... one day my MBP M1 won't either.

Not updating your browser will net you tons of exploitable vulnerabilities.

How do you expect things to ever change if no one ever updates? Certainly even if you decide to lean towards maximum support it’s still a positive these features are being introduced so you can use them in 10 years.

> Is this increasing complexity in the Web layout world worth it? Anyone who wants to use this is going to drop support for older browsers (and, in so doing, older machines that can't run newer OSes and newer browsers).

If you’ve been at this for a while, it’s important to remember that browsers update a lot faster than they used to. Anchor positioning came out last year, for example, and all of the major browsers support it by now. Very old devices are a problem but security is purging those out faster than used to be the case.

We also have better tools for progressive adoption since you can easily query for things like CSS feature support. In this demo, they didn’t implement fallbacks but in most real sites you’d have something like a basic grid layout which is perfectly serviceable for the fraction of users on old Firefox releases.

> Maybe sites could check for CSS feature support too? But they seem not to.

Certainly can: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/A...

> Is this increasing complexity in the Web layout world worth it?

Yes. I held off learning about CSS Grid for a very long time and as soon as I did I was converted. Sometimes I think the web doesn’t get enough credit for its ambition: mobile viewports, desktop viewports, touch interaction, pointer interaction, complex documents, webapps… it’s a lot. But you get some complexity as a side effect. The complexity we do see these days isn’t invented out of whole cloth, it’s standardising and improving layouts people are implementing with JavaScript, often badly.

What does the age of your machine have to do with browser compatibility issues? Are you running a stale OS and a stale browser on that OS?

If enough consumers aren't able to use the website, then business wouldn't use it. The reality is new computers aren't that expensive (I see used M1s for under 1k) and consumers are upgrading.

Yes it is. Developers write bad code when they try to work around the lack of features with ill thought out hacks, this results in a bad website for everybody, even those of us that keep our software up to date, and just so happen to have a different screen resolution and a different browser then what the developer tested on.