Hacker News Reader

Comment by culi | Hacker News Reader

Ladybird and Servo are exciting and much needed projects since Microsoft abandoned their own independent browser engine to use Chromium.

If you didn't know you could see the massive progress both projects have made in web compatibility here: https://wpt.fyi/results/?label=master&product=chrome&product...

As of today, browsers pass this percent of tests:

  Chrome: 96.82%
  Firefox: 95.41%
  Safari: 94.97%
  Ladybird: 89.30%
  Servo: 78.61%

View on HN

One interesting thing covered in the Ladybird monthly update videos, is that most of the web platform tests are text encoding tests for Asian languages.

If you remove them, Ladybird is closer to 60% and Servo to 50%.

Still good, and the point still stands that they are making amazing progress. But probably more accurate because that last 10%-20% are going to get harder to chip away at.

That's interesting and it explains why the wpt.fyi website doesn't show a percentage but instead the number of tests.

There are tons of other examples of these easy points in the test suite. Ofc text encoding tests are important if we want the internet to truly be global

I guess these percentages are kinda useless by themselves but still useful to track progress when you put them together in a historical graph

Yeah it's crazy that they don't weight the tests. AVIF support is 1 test, whereas WebCryptoAPI is 50k.

AVIF support is irrelevant. JPEG, PNG and soon JPEG XL is all you need.

Be careful you don’t mistake that for web standards compatibility.

There are many tests in there for non-standard Blink-only APIs that Google implemented unilaterally, which both Mozilla and Apple rejected on security and privacy grounds.

For instance WebUSB accounts for 845 tests, and WebNFC accounts for 173 tests. Neither of these are web standards, they are Blink-only Google APIs.

While I don’t doubt that there are bogus tests in there, looking at how many of them Safari and Firefox pass does not indicate that they have rejected many of them.

Web NFC:

> Status of This Document

> This specification was published by the . It is not a W3C Standard nor is it on the W3C Standards Track.

— https://w3c.github.io/web-nfc/

> We oppose this feature and will not implement it.

> We do not believe a permission prompt is a sufficient mitigation for the serious security and privacy risks raised by this specification. In addition, we think exposing direct hardware access to the web is a bad idea and compromises the device-independence of the web platform.

— https://lists.webkit.org/pipermail/webkit-dev/2020-January/0...

> We believe Web NFC poses risks to users security and privacy because of the wide range of functionality of the existing NFC devices on which it would be supported, because there is no system for ensuring that private information is not accidentally exposed other than relying on user consent, and because of the difficulty of meaningfully asking the user for permission to share or write data when the browser cannot explain to the user what is being shared or written.

— https://mozilla.github.io/standards-positions/#web-nfc

WebUSB:

> This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.

— https://wicg.github.io/webusb/

> WebKit declined to implement several APIs, including WebUSB, due to concerns over fingerprinting

> We have previously stated privacy concerns, thus the concerns: privacy label. We agree with Mozilla's security concerns raised in their standards position issue, thus the concerns: security label.

— https://github.com/WebKit/standards-positions/issues/68

> Because many USB devices are not designed to handle potentially-malicious interactions over the USB protocols and because those devices can have significant effects on the computer they're connected to, we believe that the security risks of exposing USB devices to the Web are too broad to risk exposing users to them or to explain properly to end users to obtain meaningful informed consent. It also poses risks that sites could use USB device identity or data stored on USB devices as tracking identifiers.

— https://mozilla.github.io/standards-positions/#webusb

Yes, they are horrible features that do not belong in a browser but they make up at most 1.41% of the test suite.

It may seem like a lot but there are 1.7 million web platform tests. Controversial chrome only web apis are few and far between the common features

At this point the web is a de facto standard platform. The whatwg doesn't decide what makes it up any more than w3c did.

As well as browsers supporting features not endorsed by whatwg, there are plenty of features that they have endorsed that browser vendors didn't bother with.

It's a standard platform, but the platform itself is not standardized, which is the point I think GP was making. The problem isn't that people don't think the web is a standard platform, but that it's hard to quantify what it means to support the web as a platform because of conflicting implementations. Standardization is ostensibly supposed to help with that, but it obviously doesn't perfectly reflect what browsers will actually support. Ultimately it the question comes down to whether people can actually use the browser with the websites they want to connect to, but that's not something that can be quantified easily due to it depending on what features websites are using and which features a browser has implemented, and network effects can make it hard to pin down what's expected at any given time, which is where all of these "imperfect" metrics like calculating some score based on the standards is coming from.

> At this point the web is a de facto standard platform.

Yes, the web is a standard platform, Blink is not. Google can’t just spit out any old privacy-violating, insecure garbage specification and call it a web standard just because it’s what they want to build. Google don’t unilaterally decide what the web is.

> there are plenty of features that they have endorsed that browser vendors didn't bother with.

Something can’t become a web standard unless there are two independent implementations. It’s part of the standardisation process. It also disqualifies things like Web NFC and WebUSB from being web standards because Google couldn’t convince anybody outside of Google to implement them.

I think you misunderstood (or don't know what "de facto" means).

> Google don’t unilaterally decide what the web is.

They absolutely do.

They don’t. We are close to that point, yes, which is why it’s so important to clearly delineate what is a web standard reached through consensus from what is Google trying to push their stuff through regardless.

If something doesn’t work in Safari or Firefox then web developers normally still hold back, so they aren’t de facto standards. We aren’t quite at the point we were when IE dominated the web. But there is a growing number of developers who blame other rendering engines for not blindly going along with whatever Google says, and that needs to be stopped in its tracks not accepted.

> then web developers normally still hold back

It takes just a few weeks on hn to see it's not true and there are a few devs who will point to the usage stats and not care about Firefox. For safari, many people just don't have access to it, so they'll never test in the first place.

Hacker News is not representative of the typical case. There are very few professional web developers who ignore Safari – a huge number of people surf on mobile and a huge proportion of mobile users are Safari, so any developer ignoring them isn’t doing a very good job. All web developers have access to Safari – if they don’t use macOS then they use a tool like BrowserStack to test in Safari. This is a standard part of a web developer’s toolchain.

I'm guessing that the "last 5% = 90% of the work" rule applies to browser engines as well ?

Idiot here: How long will it approximately take until we see a real Ladybird or Servo browser in production, that is actually usable and e.g. has addons?

Like, will it be 6-12 months, or more like 2-3 years?

I think Andreas Kling said they aim for their first release in 2026.

what ever became of khtml? i remember back in the day it had the nicest codebase of all of the browser layout engines.

Basically became webkit. Which google forked for Blink/Chrome

Damn

I was entirely unaware that both Chrome and Safari can trace their roots back to KDE of all projects. I always just assumed big corpos like Google and Apple would just roll their own from scratch.

It was easier to just take a competitors engine, let me chase the new web standards, and slap a new UI on it. Edge and Opera both use Blink, so also trace back to KDE.

Who would have guessed that Microsoft's web browser would end up being based on KDE's web engine?

Who would have guessed that all major proprietary browsers would be using KDE's web engine, while most of the open source community used Netscape's one?

Only in the sense of a browser engine Ship of Theseus. By the time Microsoft adopted Blink that KHTML code was long gone.

Webkit was forked from khtml, but the original died along with Konqueror, which couldn't keep up with javascript API changes & performance.

lots of relevant interesting reading on the webkit wikipedia page: https://en.wikipedia.org/wiki/WebKit

seems it was a quite complicated matter that included clashes between open source and commercial concerns.

https://web.archive.org/web/20090210230809/http://www.kdedev...

It eventually forked into Webkit / Chrome.

These are interesting stats, but it makes me wonder what those tests exactly are. Are there 3.18% of tests that no browser passes? How applicable are most of these tests to real world websites?

No, likely much less than 3.18%. Chrome passes the most but there are plenty of tests that only Chrome passes or only Chrome doesn't pass

Are the last percents harder to complete ? (law of diminishing returns)

For Ladybird - Andreas Kling called out that the vast majority of "easy tests" are passing and each additional test is going to be more difficult to come by going forward.

https://www.youtube.com/watch?v=-l8epGysffQ (1 minute - 4 minute)

As another comment pointed out, some of them will never be implemented on purpose. These tests aren't all backed by web standards. E.g. one test suite is for compatibility with non-standard Blink APIs

Also there are new tests being added all the time

Hasn't Servo been around much longer than Ladybird? Has it stagnated?

Servo was on a multi-year development hiatus, which is the reason this is news (see the graph in the article). In addition the original priority of Servo was not to broadly implement web standards, it was as a proving ground for Rust components to be uplifted into Firefox (I'm unclear whether or not those components, which have surely been continually developed since then, have been backported into Servo).

>(I'm unclear whether or not those components, which have surely been continually developed since then, have been backported into Servo)

I believe the article makes clear that they have.

>Servo main dependencies (SpiderMonkey, Stylo and WebRender) have been upgraded

Whisper it but C++ is probably a better language for building a FOSS web browser engine than Rust.

There’s simply more C++ programmers around, and you need as many bodies as possible for such a large project. There’s also precious few Rust developers with experience with large projects since Servo is the largest project.

Reply on news.ycombinator.com