4 ms·

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

by culi 2y ago

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=firefox&product=safari&product=ladybird&product=servo&aligned 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%

materielle 2y ago
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.
- culi 2y ago
  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
- IshKebab 2y ago
  Yeah it's crazy that they don't weight the tests. AVIF support is 1 test, whereas WebCryptoAPI is 50k.
  - Release0381 2y ago
    AVIF support is irrelevant. JPEG, PNG and soon JPEG XL is all you need.
wiz21c 2y ago
Are the last percents harder to complete ? (law of diminishing returns)
- igrunert 2y ago
  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 https://www.youtube.com/watch?v=-l8epGysffQ (1 minute - 4 minute)
- culi 2y ago
  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
a-dub 2y ago
what ever became of khtml? i remember back in the day it had the nicest codebase of all of the browser layout engines.
- madeofpalk 2y ago
  Basically became webkit. Which google forked for Blink/Chrome
  - yonatan8070 2y ago
    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.
    - pests 2y ago
      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.
      - IshKebab 2y ago
        Who would have guessed that Microsoft's web browser would end up being based on KDE's web engine?
        lmm 2y ago
        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?
        zarzavat 2y ago
        Only in the sense of a browser engine Ship of Theseus. By the time Microsoft adopted Blink that KHTML code was long gone.
- 2y ago
JimDabell 2y ago
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.
- LeFantome 2y ago
  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.
  - JimDabell 2y ago
    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/ 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/031007.html 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 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/ 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 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 https://mozilla.github.io/standards-positions/#webusb
polyaniline 2y ago
Hasn't Servo been around much longer than Ladybird? Has it stagnated?
- kibwen 2y ago
  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).
  - KwanEsq 2y ago
    >(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
  - zarzavat 2y ago
    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.
yonatan8070 2y ago
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?
- culi 2y ago
  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
upcoming-sesame 2y ago
I'm guessing that the "last 5% = 90% of the work" rule applies to browser engines as well ?
wobfan 2y ago
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?
- brodo 2y ago
  I think Andreas Kling said they aim for their first release in 2026.

by culi 2y ago

materielle 2y ago

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.

culi 2y ago
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
IshKebab 2y ago
Yeah it's crazy that they don't weight the tests. AVIF support is 1 test, whereas WebCryptoAPI is 50k.
- Release0381 2y ago
  AVIF support is irrelevant. JPEG, PNG and soon JPEG XL is all you need.

wiz21c 2y ago

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

igrunert 2y ago
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 https://www.youtube.com/watch?v=-l8epGysffQ (1 minute - 4 minute)
culi 2y ago
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

a-dub 2y ago

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

madeofpalk 2y ago
Basically became webkit. Which google forked for Blink/Chrome
- yonatan8070 2y ago
  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.
  - pests 2y ago
    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.
    - IshKebab 2y ago
      Who would have guessed that Microsoft's web browser would end up being based on KDE's web engine?
      - lmm 2y ago
        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?
      - zarzavat 2y ago
        Only in the sense of a browser engine Ship of Theseus. By the time Microsoft adopted Blink that KHTML code was long gone.
2y ago

JimDabell 2y ago

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.

LeFantome 2y ago
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.
- JimDabell 2y ago
  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/ 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/031007.html 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 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/ 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 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 https://mozilla.github.io/standards-positions/#webusb

polyaniline 2y ago

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

kibwen 2y ago
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).
- KwanEsq 2y ago
  >(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
- zarzavat 2y ago
  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.

yonatan8070 2y ago

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?

culi 2y ago
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

upcoming-sesame 2y ago

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

wobfan 2y ago

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?

brodo 2y ago
I think Andreas Kling said they aim for their first release in 2026.