Kerrick
commented
11 months ago Another good reason to support WebKitGTK is because it’s the rendering engine used by Tauri apps on Linux. Plenty of developers who want to use web tech to make native apps choose Electron because it’s got the same features on any platform, but this could be helped by CanIUse. Rather than choosing between Known Chromium and Unknown & Different, CanIUse can change it to a choice between Known Chromium and Different but Known.
TingPing
Summary / TLDR
In current features matrix tables, CanIUse's browsers include Chrome (Blink), Edge (Blink), Safari, Firefox, Opera (Blink), IE (dead), and a long tail of somewhat niche mobile browsers… but it does not include WebKitGTK-based browsers like Epiphany (a.k.a. GNOME Web), which are the industry's best kept secret.
I believe WebKitGTK should have at least some representation there as the "4th" engine; it would be more helpful for web developers to consider that than the multitude of me-too Blink-in-a-trenchcoat Chrome clones (including Edge, Opera, Brave, Vivaldi, etc. etc.) or the defunct "IE".
An example of how this absence of representation affects the real world: in Q4 2023, in practice, we now have not "only" Safari supporting JPEG XL by default in a public production release, but also all recent WebKitGTK-based browsers like Epiphany... they are effectively "the fourth engine", yet they are not represented in CanIUse's JPEG XL page, so web developers think only Safari supports this format by default, which is untrue.
"Shouldn't we call it Epiphany?"
The tricky part is that, in the world of open source browsers based on WebKitGTK, feature enablement depends on the WebKitGTK version (i.e. it's not about the Epiphany version), so it would need to be WebKitGTK itself and not "Epiphany" that gets added to the table. WebKitGTK is 99.9% of the browser.
As we know, the browser engines landscape is different from the mid-to-late-2000's, so this might be an opportunity to rethink CanIUse on a engine-centric way rather than "browser app brand", but that's beyond the scope of what I'm proposing here, which is to at least add something for WebKitGTK as it is today's "fourth player", in practice.
"Wait, isn't this the same as Safari's WebKit?"
WebKitGTK (and WPE WebKit) are pretty Linux-centric, they are ports "based on, but different from" WebKit itself (which is mostly MacOS and iOS nowadays, for Safari). As a result, the featureset and state of implementation/integration is not on the same level, with very different technologies involved (the whole graphics and multimedia stack comes to mind; X11 and Wayland, GStreamer and Pipewire, libsoup, gnutls, etc.).
There's a multitude of browsers on the desktop (such as Epiphany, and others) and on OEM embedded/IoT/multimedia devices (such as smart TVs, set-top boxes, digital signage, etc. industries where Linux owns the market), we don't hear about them much, but they ought to be an important consideration for web developers using the caniuse website to determine the spread of certain features throughout the web engines ecosystem.
I would argue they are more relevant "in the market" than most of the long-tail of browsers currently on CanIUse beyond the big three high-profile ones (Firefox vs Safari vs Chrome/Chromium and its gazillion Blink doppelgangers). Part of the reason they are underrepresented in web usage statistics is that they purposedly are flying stealth. For example, Epiphany just straight-up pretends to be Safari (albeit on Linux): you'll get user agent strings like "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.4 Safari/605.1.15" because everybody pretends to be everybody else (otherwise half of the web breaks).
For "most" of the features, Epiphany is identical to the Safari version that it claims to be (with a few exceptions, mostly due to features disabled due to requiring more work to finish implementing in the GTK port), and the release pace/timing being different in general.
That said, there are quite a lot of technical differences between Safari vs. WebKitGTK, to the point that I have to write this whole request. For example,
requestIdleCallbacklast week, but only for Apple, not for WebKitGTK.…etc. I'm sure WebKitGTK developers could cite plenty of points of divergence in the architecture and timing of features enablement. It goes both ways: there are various limitations on the Apple side that do not exist on Linux, and vice versa.
"How does WPE WebKit compare to WebKitGTK?"
I am told (by one of the Epiphany developers) that those two Linux-based engines are the same thing, more or less.