Addition of data for the SerenityOS Browser

[linusg]

Hi there! As part of the SerenityOS project we're developing a web browser, simply called "Browser", and referred to as the "SerenityOS Browser" in contexts outside of the system. I'd like to get some thoughts on adding compat data for it to BCD, feel free to share anything from related anecdotes to a plain "yes/no/maybe later" :)

FWIW, caniuse already expressed unwillingness to add browsers below a certain usage stats threshold (in the context of NetSurf), but AFAICT they have no formal rules on this.

Some background info

• It is completely from scratch, and as such cannot source its stats from any other engine. No "upstream version of chromium" to look at for compat info :)
• It aims to eventually be fully on par with modern browsers and web technologies, in some cases already implementing bleeding edge proposals on top of the stable specs, especially in the JS compartment (most notably Temporal)
• It however doesn't aim to gain the largest possible userbase - the goal is a fully functional web browser for its own developers and other interested individuals, but at no point will there be marketing campaigns, ports to as many systems as possible, etc. This might pose the biggest issue here, and if projects such as BCD and caniuse adhere to a 'usage stats' based approach for inclusion, we'll likely never make it into either.
• Development is active, averaging 300-500 specifically browser-related commits per month in recent months (and many more in other possibly relevant areas, such as the graphics library)
• Compatibility isn't generally poor or great, but varies a lot across different areas. Areas of development are mostly based on each individual contributor's interests. I think this is one of the most interesting aspects for inclusion into BCD, giving both ourselves and outsiders a better idea of the overall state feature-wise.

Prior art

No compat data in BCD's sense, but various things related to tests suites & collecting data from those:

• Test runners for the JavaScript and WebAssembly engines (running https://github.com/tc39/test262 and https://github.com/WebAssembly/testsuite, respectively), continuous data is published and visualized at https://libjs.dev/test262/ and https://libjs.dev/wasm/
• Able to run the Web Platform Tests, but no automation or capturing of results as of yet
• Integration into esvu (#33), pending integration into eshost (#116), hoping to eventually appear on https://test262.report/, and similarly https://wpt.fyi/ for WPT

Addressing BCD's requirements for adding a new browser

---

From https://github.com/mdn/browser-compat-data/blob/main/docs/data-guidelines.md#addition-of-browsers:

BCD's owners may choose to adopt a new browser or engine. To add a new browser to BCD, we need evidence of (in decreasing order of importance):

---

a compelling downstream-consumer story (e.g., MDN or caniuse express an interest, or someone is planning to do something with the data that might plausibly grow BCD's reach)

The preferred outcome would of course be a column on MDN's and/or caniuse's compat tables, but as mentioned above this might be difficult to achieve on caniuse specifically. I haven't asked about or looked into inclusion into MDN yet.

Even if this is not feasible at the moment and we'll end up publishing our own representations of the data as we currently do for the test suites, having it freely available in BCD would:

• Increase compatibility with existing consumers of browser compat data
• Make a later integration into said websites effortless
• Allow us to use existing tooling and data formats, and focus on actually gathering and maintaining the data instead

reviewers (e.g., two or more people with interest and ability to test data relating to new and existing releases, or at least one reviewer acting on behalf of the vendor)

As far as the vendor is concerned, I'm happy to lead the efforts of adding, updating, and reviewing the data. I can only speak for myself, but I'm sure we could find more developers from within our own community interested in helping with this.

a release process allowing BCD to publish stable release information in a browsers/ file (containing release notes with version numbers and dates)

There are no versioned releases in the typical sense at the moment, it's more comparable to a rolling release. Data would be attributed to a "version 1" as per https://github.com/mdn/browser-compat-data/blob/main/docs/data-guidelines.md#initial-versions-for-browsers.

documentation (e.g., how to get and test a feature in that browser, links to resources that might help with it, etc.)

Somewhat scarce at the moment on our end, but happy to properly document as needed in either repository.

[linusg]

@Elchi3 @foolip @queengooborg @Rumyra any thoughts? 🙂

[queengooborg]

Hey @linusg, I checked out the project and am amazed with what you've been able to do on it, it's pretty awesome and I'm excited to see where it goes! I've added this to our meeting agenda to discuss during the next BCD meeting!

(We're currently in a transitional phase since Daniel has stepped down as an owner and Florian is on sabbatical, so decisions may be a bit slower than normal. Thank you in advance for your patience!)

[foolip]

If there's just a single bit of information per BCD entry, I wonder if it would be possibly to try this out outside of BCD? Given a list of BCD paths, it would be trivial to patch BCD to a BCD+SerenityOS JSON file, and to use that for whatever purposes you have in mind.

Regardless of whether the SerenityOS browser is included in BCD, updates to https://mdn-bcd-collector.appspot.com/ to better detect support would be welcome.

[Seirdy]

There’s always the possibility of including SerenityOS data in the MDN BCD tables, but not displaying it on MDN just yet. This could give other projects a chance to use these tables for their own purposes. I think a lack of information on feature compatibility is one of the things holding back website compatibility with non-mainstream engines.

Non-mainstream engines are in a bit of a “catch-22” situation: enthusiast developers don’t support them because there’s not enough compatibility info; users stick with mainstream engines due to better compatibility; and other developers don’t support alternative engines because nobody uses them. Introducing some docs won’t break this cycle, but it could disrupt the cycle ever so slightly.

I would love to see feature comparisons of alternative engines (SerenityOS LibWeb, NetSurf, litehtml, Flow Browser, Servo, et. al.). Maybe including just one alternative engine could be a step in that direction, and the SerenityOS browser looks like the most active of the bunch.

POSSE from https://seirdy.one/notes/2022/08/08/re-addition-of-data-for-the-serenityos-browser/

[Seirdy]

Moreover: as an outsider, I've noticed Andreas Kling active in WHATWG discussions and filing helpful bugs on issue trackers for standards. Even if it isn't quite mainstream, SerenityOS' LibWeb does seem to have a helpful role in web interop.

[ris-work]

Considering that SerenetyOS's libWeb and Ladybird are almost entirely written from scratch (no shared lineage with WebKit/KHTML), I'd love to see it in the list as well (as an outsider). It is probably the third independent browser (as others are just Safari/Chromium/KHTML clones and Firefox/NN clones).

[linusg]

I'm no longer involved in the project and a bunch of information in the original post is outdated by now (including the browser's name), if someone else wants to pick this up please file a new issue.