Microsoft tried to sell it as a promise of Windows Phone 10. It mostly worked just around the time that Microsoft killed Windows Phone.

When IE was the Emperor it was seen as IE's behaviors were the standards. The perspective at the time was that the other browsers were non-standard. That did get codified into the standards eventually. `* { box-sizing: border-box; }` that is towards the top of almost every "reset.css" is CSS standard for "use the IE box model". XHR was named XmlHttpRequest as an IE quirk and that set the standard we still mostly follow today; `fetch` is a nicer API but we still colloquially call it a part of/relative to/replacement for XHR including various browsers' Dev Tools where to focus on `fetch` requests you click the XHR tab.

Both of those things (and others) became "standards" when IE was moving quickly and breaking things. It took a while for the actual multi-browser standards to catch up. XHR took a few years to show up in non-IE browsers. CSS `box-sizing` wasn't added to the CSS standards until 2012 (11 years after IE6 was released, the "last" version of IE for a long time; five years without a new version). A lot of the web was built easier on those things or better with those things which lead to so many people using IE up to IE6 as their primary browser and so many developers building IE-only websites up to IE6.

Again, as a developer it can be easy to remember the pain of still supporting IE6 in 2005 (five years before tools like `box-sizing` made it a lot easier to support similar CSS for both IE and non-IE browsers, and a year before IE7 finally broke the "IE6 is the last IE" problem). It seems a lot harder to remember why we were still supporting a "dead"/"final" IE6 in 2005 or still supporting a "dead"/"final" IE6 in 2012 when IE10 was fresh and new and very standards compliant (including supporting both `box-sizing` modes) but not yet winning over the crowds of legacy sites: everyone was using IE6 until Microsoft killed it. A lot of things were built for its version of "standards" (many of which were better/easier to develop for versus their contemporary real standards) and couldn't be easily upgraded until the real standards also caught up to how fast IE had been innovating/changing/upgrading the standards.

The risk to the web platform that I think IE represents the most cautionary tale about is relying too much on the browser rushing ahead of the standards, because it could stop at any moment and may take a decade or more for the standards to truly catch back up. Because they did.

If Google decided today to do a "The Browser Company-style pivot" because the Age of AI means that browsers are dead, everything a browser can do should be done through agentic automation, and asked all of the Chrome team to switch to some new agentic harness or accept a soft layoff, how much work would there be to move websites out of being "Chrome-only" or built on top of Chromium? (Which to be further unfair is also sort of what feels like is already left of Microsoft's Edge team working in Chromium today.) It's real easy to imagine that hypothetical, I already named two companies working with Chromium that have just about done exactly that. The hypothetical is not that far from the inside baseball of what happened to IE6 where Microsoft thought browsers were "done" and pivoted the IE team to new roles on "higher priority" Windows work and/or soft layoffs.

We remember the pain of having to support older versions of IE pretty well, but not enough of us seem to remember the pain of how we got to that point and how easy it feels like companies could do that to the web again. Safari lagging current standards is a relatively smaller problem compared to if Chrome gets burnt we suffer another "internet dark age" of supporting ancient browsers for a decade or two due to legacy apps and in turn legacy users that don't or won't upgrade.

(Some would argue that can't happen in the same way that IE did because Chromium is open source and already has many forks. I can't help up but bring up examples like the word "diaspora" and the tale of "the Tower of Babel" that a messy soup of forks that no one can agree on as the new "standard" can be its own slow train wreck disaster.)

Which is the exact problem any other IPv4 "extended" proposal would have hit. But the practical reality if the port number really was the only freely available bits in the IPv4 header to reasonably extend into. Almost everything else had ossified middleboxes doing something dumb with it. (And we've seen from NAT/hole-punching/etc how even port numbers had a lot of assumptions to overcome from middle boxes and we aren't using a full /16 there either. A lot of the safest traffic has to be > 10,000, a constraint on 14 of those 16 bits.)

There was never 64-78 bits in the IPv4 header unconstrained enough to extend IPv4 in place even if you accepted the CGNAT-like compromise of routing through IPv4 "super-routers" on the way to 128-bit addresses. Extending address size was always going to need a version change.

> It is bizarre that you're "pinning" this on the Chromium engineers - who are essentially the only ones moving the web forward.

I'm saying this is exactly the problem. If the perception is that only one browser is "moving forward" and the rest are just chasing that moving target, that's not healthy and it is not a standards process. WHATWG has always been at risk of "regulatory capture" by Google or at least Chromium interests. More so than ever there are standards that seems like WHATWG rubber stamped whatever Chrome decided to do without larger consensus work with Safari and Firefox. That's really dangerous for the web platform. (And W3C lost to WHATWG and seems increasingly irrelevant as a standards body for HTML.)

I think we are all very lucky that ECMA hasn't so far shown the same risk and TC-39 (JS) continues to look overall diverse and healthy.

> Google doesn't and, in fact, can't "make standards". Standards are something that comes about through the painful diplomatic process described in those links.

This is why I put standards in quotes in most of that comment. I do think WHATWG has already signed off on Chrome-first things as "standards" that aren't in the sense of multiple robust implementations and a diverse enough number of stakeholders that aren't just using Chromium-derived codebases. I worry WHATWG is at risk of getting worse in this.

> As for MPA PWAs, there's nothing at all stopping you from serving pages from a service worker. There's plenty of valid and accessible ways to precache all the pages that a user might need while offline. Workbox (from Google!) makes it easy, but its also easy to hand-roll.

As very personal experience from building PWAs (and failing to build many more of them): Workbox is bloated and awful to work with and is bad enough at SPAs that trying to feed it an MPA makes me want to scream just thinking about it. Hand-rolling a Service Worker remains a nightmare because the API is awful to work with by hand, which is the whole reason Workbox exists. There's something very wrong with the APIs that right now the only answer seems to be "just use Workbox". That's not healthy for the web platform to be so dependent on a single vendor's tool to get over the hump of using a web API. (Even if that tool is open source. CVEs affect open source like everything else.)

The last time I was serious about PWA development I broke down in tears and switched to Ionic's Capacitor and Electron because browser wrappers are still too much easier than writing a PWA.

I know that isn't just me also anecdotally by the number of Electron apps running on my machine even right now (a bunch) and the number of PWA apps running on my machine (none).

Statistically Service Workers and Workbox are massive failures, and it isn't Apple's fault and it is weird to me claiming that it is entirely Apple's fault. If you don't want to blame Google or at least Chromium engineers, that's fine, we don't have to agree on that. But show me the app with a working PWA ServiceWorker that has a good reliable caching strategy, good offline-first support, and people use that offline-first capability regularly and I'll show you a unicorn. The APIs are terrible, the standards should be better. If we don't want to point fingers at why the current APIs and standards are so awful, can we at least find someone to point a finger at who is actively working to make them better? It doesn't seem to be "Just Use Workbox" Chromium. Who is actually trying to move the offline-first web forward towards pragmatic reality and not just "we support it in theory, with this one JS library, but very few are using it in practice and almost none successfully"?

> And, Microsoft most definitely has not given up on the web platform - they literally adopted and make contributions to chromium. The author of that site literally works at Microsoft now, coaching both internal and external teams on improving their use of the web, as well as contributing to standards.

When Microsoft switched to Chromium they soft laid off a lot of their web platform staff. Chromium Edge's outward development focus seems to be AI and First-Party Coupon Cutting Extensions.

Spartan Edge had ideals and seemed to really believe in the PWA as a first class application platform. For a time, I had a bunch of PWAs as daily use applications in Windows 8 and early 10 (not all of which I built myself, either). That era is certainly gone now. WebView2 is making some inroads in reduce the reliance on Electron by certain types of apps, but WebView2 isn't a PWA platform, it is another end run around it/away from it.

> I dont see any point in continuing this discussion, as you haven't shown even the slightest interest in considering how you're living in some bizarro world.

> If you are actually attempting to communicate in good faith

You've strayed close enough to the realm of ad hominem attacks that I'm going to stop here. It doesn't sound like we are going to ever agree, but certainly not because I'm not debating in "good faith" or living in some "bizarro world". It seems rude to me to imply such accusations. Just because I have a different perspective doesn't make me a bad actor nor prove I have some sort of mental health issues. I may have experienced a different world than you have in my career, but there was nothing "bizarro" or worse about it. Different perspectives should be a joy to engage with, not an affront to ridicule. I'm sorry I couldn't find help you find common ground.

With more and more players expecting emoji support in text entry boxes, more games are starting to ship with full unicode support. Also I've noticed optional ligatures that OpenType supports have become a big style thing in certain game genres/by certain studios. Harfbuzz's "Old MIT" license shows up more often in the credits of games and game engines.

I don't know if that's a good reason to push to standardize controller glyphs to Unicode, though.

(ETA: Plus the other obvious reason more games and game engines are bringing in full Unicode support is localization, especially for Arabic and CJK. We're a bit past the point where AAA games only feel a need to support EFIGS. The Middle East and Asia are huge markets, especially for mobile games.)