Hacker Newsnew | past | comments | ask | show | jobs | submit | troupo's commentslogin

> A browser (or anyone) comes up with a spec, a browser can ship it (to test the waters in an origin-trial, to gain traction if they believe in it), and the standard (often) comes after the fact:

1. Google often doesn't bother even with a spec. Or it creates a semblance of a spec, throws it up on a googler's Github account, ships it and advertises it as "emergin standard" on web.dev

I mean, the status of many (if not most) of the APIs that these sites push are literally "napkin scribble, not on any standards track".

2. Google pushes a lot of APIs quickly into production even if there's a very explicit open objection from other browser vendors (any objections are routinely ignored: from general objections to the shape of APIs to whether it can even be implemented outside Chrome).

3. I wouldn't really quote Alex Russel on anything related to standards, as he is responsible (directly or indirectly) for quite a few of those because of his work on Web Components. E.g. Constructable Stylesheets were shipped in Chrome because Google's own lit project needed them. They shipped it in production when the design contained a trivially triggered race condition, it was called out, and Google completely ignored it because "users want it" or something.

4. Browser vendors quite literally agreed not push incompatible only-exists-in-one-browser shit after the browser wars. The whole standards process is designed to minimize this. Well, Chrome is the dominant browser, so of course they shit all over the process, and quite a few people cheer them for that.

Internet Explorer in the 2000s: shits out a bunch of own non-standard crap, people boo them

Chrome in the 2010s-2020s: shits out a bunch of own non-standard crap, people cheer and blame other browsers for not implementing this crap because... Google is "the champion of open web" or some such bullshit.


I keep asking: Android doesn't have all these perceived limitations. Where are all the amazing native-like PWAs on Android?

If a web app doesn't work on iOS, a business builds a native app instead. iOS is too important. So that fantastic native-like PWA never gets built in the first place.

Apple is not just holding back PWA on iOS, they're holding back the entire web everywhere.

Compare that with desktop, where web apps (maybe not PWAs, strictly speaking) are dominating: Gmail, Office/Docs, GitHub, Figma, you basically do everything in web apps.

And if you count Electron [1]: VSCode, Slack, Spotify, etc, etc.

[1] Importantly, Electron lets you bring your own (browser) engine. You can build a native app on iOS that is just a wrapper around a web app, but it has to run on iOS' WebKit, and is thus limited by what Apple deems worthy


Note how it doesn't list which of these are Chrome-only non-standard APIs that Firefox doesn't support either.

Oh wait. You don't care about small details like that. None of these Chrome shilling websites do.


Did you try opening the page? Each feature says which spec it's part of (e.g. "W3C Draft", "W3C Candidate") with a link to it. It also shows which browser implemented a feature first. Often it's Chrome, but sometimes it's Firefox, Opera, or even desktop Safari!

Likewise, you can click on the Chrome icon to change comparison browser. Here's a list of features implemented in Firefox on Android but not in Safari on iOS (and therefore, not in Firefox on iOS either):

https://ios404.com/?browsers=andff

Fwiw, I've been a Firefox user for about 9 years. I would love to see Firefox be able to ship their engine on iOS. The main reason Firefox haven't implemented as many features as Chrome is that they lack the resources to. Anti-competitive behaviour has hurt them a lot, and being forced to use a sub-par, undifferentiated browser engine on iOS - the world's most valuable and influential OS, has played a big part in this.


Hi! Creator here (of iOS404) - you can filter level of standard and compare to FF Android (or compare to Safari Desktop, or any mix) instead if you'd like.

First of all, features can be a standard without (full) FF and/or Safari support.

Second, Safari has a monopoly on iOS and controls what other browsers can support on the platform (that also usually means "less than Safari", because SF gets to support things first). They are in a unique position to hold back the entire web, even on other platforms. They're holding the standards hostage by not allowing the market to decide which features are important to them (and put pressure on Safari and FF to implement them)


> the open webm

Sonehow you seem to confuse open web with Chrome-only non-standard APIs


No, because any browser can decide to ship a feature that it thinks is worthwhile. Users can decide which browser they trust to be their User Agent. The distribution model is open. You type a URL, you click a link. No single company in control.

> No, because any browser can decide to ship a feature that it thinks is worthwhile.

Yes, yes they can. They don't get to call it standard or essential. And Chrome-shilling sites like the pwa.gripe and a slew of others don't get to call those features "essential standards of the web".

> No single company in control.

That is literally not how standards work in the browser world by literal agreement of all browser vendors.

We literally lived through this with IE pushing its own non-standard features and calling it a day. Hence the whole "let's reach a consensus, and have several independent implementations of a feature before calling it a standard".

And if "no single company is in control", why then you're so enthusiastically pushing for a Google's full control of the web?


Imagine if these countless of "Safari bad" sites didn't shill for Chrome by pretending that Chrome-only APIs are essential and standard web apis.

> Chrome by pretending that Chrome-only APIs are essential and standard web apis

Reminds me of the days when all the corporate coders thought the IE apis were the only ones worth using.

So if you accessed $megacorp website on a non-IE browser it was your fault for not using IE and not their fault for failing interop.


I noticed how they've marked the features that only Chrome supports (e.g. installation) but not the feature that only Firefox supports (orientation).

(tbh I don't know if the list is simply Chrome-centric or if there's a good reason behind, but it struck me as interesting)


yeah I'm using mobile Firefox and it has an awfully high overlap with Safari. Almost like a bunch of the stuff Chrome supports isn't actually a standard at all yet...

Most apps at the time managed that quite successfully. IIRC Adobe Photoshop was an MFC app. There was no other API but Win32 API.

If you read beyond just the headline, you can see a description of the problem with a bunch of links in literally the first paragraph of the article.

And if you run the command you can see that there's still lots of icons in menus

In article we discuss has a link to this article: https://blog.jim-nielsen.com/2025/icons-in-menus/ Which has a good paragraph with an example:

--- start quote ---

Get a bunch of people in a room, show them menus where the textual labels are gone, and see who can get the most right.

--- end quote ---

Icons won't help you when they are inconsistent, or don't mean anything.

It's impossible to find a suitable visual metaphor for every possible action of every possible app and cram it into a tiny monochrome icon.


Why would they backtrack? Alan Dye wasn't the only person at Apple pushing this with God-like powers overriding everyone's decisions. [1]

New head of design, surprise surprise: Apple's new software design chief, Steve Lemay, was "a driving force" behind Liquid Glass and was "deeply involved in its development." https://www.macrumors.com/2026/03/15/ios-27-macos-27-no-majo...

[1] I have small rant about this pervasive view here: https://dmitriid.com/the-curious-case-of-alan-dye


I've had carrots (and fruit and hard snscks) since I don't remember when.

My teeth have been crooked since forever. So?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: