As of a week ago their pre-alpha version was capable of running my extremely heavy JS+ SVG + worker thread + SSE app, a bit slowly I admit but correctly in all major exercises I tried. So, I'm optimistic. They're doing great.

Separately I wonder if the compatibility job is easier now that you can just give the HTML5 spec to Fable and Bob's your uncle.

But I agree, it's impressive. My blog uses a lot of modern CSS features (such as nested selectors), and this latest version rendered almost perfectly. Much better than Servo. Still, this small gap is often the difference between a normal browser and a browser that is a pain. Safari has much, much better compatibility, but even then this browser is hated for it's quirks, because even much smaller compatibility gaps are quite noticeable.

> Safari has much, much better compatibility, but even then this browser is hated for it's quirks

I think this meme has almost run its course.

Funnily enough I just had to fix a Safari layout quirk yesterday (for iOS 16 & 17 devices only). I was excited to pick it up because it had been _so long_ since I had to deal with a CSS-related browser incompatibility. I was nostalgic :')

I raced Claude to fix it. I knew which CSS had the issue, but I needed to set up an iOS simulator to verify my fix. So I had to download xcode, which download 10GB of data for a current simulator and Apple's embedded code-assist model. Then another 8GB for the iOS 16 simulator.

Claude took about 5min to find the right CSS file and then got stuck at the same point as me: needing to simulate it to verify. It just got the old webkit binaries and hacked together its own minimal browserstack clone.

It finished before me because of those downloads, but it only found half the fix. So... I won!

Except...I made a typo (`no-wrap` instead of `nowrap`) and had to do a fixup commit.

So I guess we'll call it a draw :(

The browser might reach 95-97% compatibility eventually. But the last 3-5% gaps are the most stubborn. Many of these 3-5% are not trivial API calls. They might be some subtle legacy quirks, timing/rendering things, etc. There is a lot of poorly written historical code that might be illegal by web standards but browsers are forced to support. Established browsers have decades of patches and regression testing.

That sounds like a reasonable estimate for the gap between any pair of Chrome, Firefox, and Safari, just from varied depth of implementation of more recent standards.

The history of Chrome and Safari traces back to KTML, the renderer for Konqueror, a niche browser on Linux with so little market share there weren't real conversations about it ever seriously competing with Firefox or IE.

Then something unexpected happened: Apple adopted KHTML for Safari's WebKit. WebKit was then adopted as the render for Chrome

Could a niche browser still become mainstream /today/? I think so.

The web standards are enormously complex compared to that time. Not sure if today's tooling can compensate this.

The complexity of web standards isn't necessarily a bad thing. A lot of the "complexity" (as usually judged by the raw size of the spec) is just existing APIs evolving to be more rigorously defined. Before that level of specificity, browser implementations varied and engineers had to make certain decisions.

A more "complex" spec can sometimes make the job of the engineer simpler.

That's not the kind of complexity that is the problem though. The complexity you have to deal with is just more and more features being shoved into the spec at breakneck speed, or if they are not in the spec, it's just Google adding them to their engine and everyone starts using them anyway to the quasi-monopoly of Chromium-based browsers.

Are they? I feel like the real difference is an insistence on actually enforcing them. There were some really strong standards at the time of IE5, it was just the wild west in terms of what got built. And then you had Tantek Çelik quietly building all of them in IE5 on the Mac. Just a question of where to look.

May just be me being a romantic. Work shut off access to non-Chrome browsers an took away Incognito Mode. Which is fun for QA work.

Not even Firefox can keep up chasing down the chromium universe.

It doesn't have to chase it down, just keep plodding along implementing the new standards as they become accepted.

Google likes to make up its own "standards" and push them out on chrome, but Safari tends to be the late-comer to supporting impactful standards, not Firefox.

Do you have a particular use-case where Firefox's lack of support blocks you?

Outside of the adoption of new standards, most of the work that goes into the big 3 browsers is more around edge cases and compat due to historical development reasons.

Ladybird can afford to be a beloved hobby browser that simply hasn't solved all the edge cases but works well 97% of the time

Yes, this is what I'm saying. It's unlikely to be a replacement for the majority of average users but can be popular among people like us.

Just a small personal touch -- my coworker is constantly pushing me to use Chrome because it "just works", but I'm stubborn as hell. Used Firefox from early 2000s. Oh how I will love to twist his nerve even more once I will switch to Ladybird. Saying this because there has been more harder days to counter these pushes. And to be honest I think we are overthinking about how much this last 3-5 % actually matter for huge crowds.

I understand that your argument still stands in big picture, but in this big world there is plenty of room for Firefox and Ladybird and there is more than enough room to grow. Firefox mostly is being held back with their organization. I'm not convinced that it is technical problem.

But then again, I'm still believing that there will be a year of desktop Linux coming. Maybe even sooner than we expect.

> I'm still believing that there will be a year of desktop Linux coming. Maybe even sooner than we expect.

It started 9 years ago.

That's the year ChromeBooks first outsold Macs in the USA. And note, that is by value, not units, meaning at least 4-5x as many Chromebooks were sold as all Mac hardware put together.

By 3-4y later this was worldwide.

So desktop Linux computers are now comprehensively outselling macOS machines and have been for nearly a decade… even with Apple's migration to Arm, which means better small machines but worse big machines.

But it's the wrong sort of Linux and so the Penguin taleban don't count it and are still arguing about... oh, systemd vs SysVinit, or glibc vs musl, or Emacs vs Vim, or something.

Eh of course we don't count a totally locked down walled garden as Linux.

It's still a Linux distro. Ext4 partitions, glibc, upstart as the init. The GUI is weird but it's just another desktop.

I don't use it myself but my wife's laptop does. So, example: it has no video player. Solution: Ctrl+Alt+T, just like Ubuntu. In the terminal, `apt install vlc`. Done. File associations and things just happened automatically. Once VLC was there, double-click a movie file on the local drive and it opened and played.

It's based on Gentoo but the bundled container-VM thingie is Debian.

ChromeOS is a lot more like any other distro than Android, which is different from the libc and entire userland on upwards.

Yeah, but it will be a Pyrrhic victory for desktop Linux if it conquers the desktop. You can't even use it normally without Google account.

Very true and an excellent point.

There is a fork that doesn't need Google accounts. It's called Fyde OS. I tried it:

https://www.theregister.com/on-prem/2025/08/21/fydeos-offers...

It is a nightmare scenario: you have a long tail of thousands of websites that are broken, a large complex codebase and you need hours of time per bug for a human to investigate and fix it. Some trickier bugs could take days to diagnose. It's not sustainable for a small team. Luckily, I think this is one of the cases where AI can be leveraged appropriately, and give them a fighting chance of catching up.

> It's impressive that they're doing such titanic work.

I think it is still a bit too early to say that. The most difficult part is to ensure the security of the implementation, and not just the checkbox compliance against standards. So when this survives the swarm of pentesters, it will be a absolute titanic work. Otherwise it might be too risky to use.

This is probably an unpopular opinion but I think that if all this effort went in to improving Firefox, or a fork of Firefox if the goal is to totally de-Google it, then that wouldn't be such a problem and it would overall be healthier for the web. I don't really understand the purpose of this titanic software engineering effort just to avoid... a default search engine setting?

> if all this effort went in to improving Firefox, or a fork of Firefox

Someone tried to instigate that on Mastodon recently. It didn't work.

https://mastodon.social/@sarahjamielewis/116959309031485270

Spread the word. Contact the developers, ask them.

The forks I know about:

• Waterfox -- https://www.waterfox.com/

• Librewolf -- https://librewolf.net/

• Floorp -- https://floorp.app/

• Zen browser -- https://zen-browser.app/

• Mullvad -- https://mullvad.net/en/browser

• Konform -- https://codeberg.org/konform-browser

Others:

GNU IceCat – https://www.gnu.org/software/gnuzilla/

Mercury – https://thorium.rocks/mercury

I fear it would be hard to get some of the earlier forks on board... these are all based on much older codebases:

• Palemoon -- https://www.palemoon.org/

• Basilisk – https://www.basilisk-browser.org/

• Seamonkey – https://www.seamonkey-project.org/

Honestly, breaking on some advanced/esoteric features is a price I'd eagerly pay to get a browser that's cleaner, more lightweight, and user-focused.