Even if Google was an absolute saint without a trillion-dollar ad business, there's still a problem of "bug-compatibility".
Without a second browser engine to test pages in, it's really hard to know what is a bug and what is intentional. Devs don't know all the specs by heart. They write whatever happens to work for them, but sometimes they accidentally depend on obscure edge cases in the implementation that were never meant to exist.
In the long term it's paralysing for the engine maintainers, because any change in implementation could be changing some subtle behavior that breaks some pages. W3C requires two independent implementations, so that they'll share intentional behaviors, but hopefully their bugs will differ.
The single-engine Web will be as fun to maintain as Windows: Windows 11 Explorer has a shiny new context menu with an option to reopen it as an older, uglier context menu, because Microsoft couldn't touch a line of code of the old context menu without breaking apps.
When you have a monoculture, it doesn't matter how good the spec is.
Even if the spec was as precise as a source code of another browser, that's not what devs are writing for, so code in the wild web will inevitably deviate from the spec.
Honestly I never understood the logic behind the "HTML spec has to be forgiving towards errors". Like, what's so special compared to any other programming language? Popularity? Excel Macro programming is probably an even more popular and widely used language by non-developers, and I've yet to see anyone arguing for more leniency while trying to put formulas inside a sheet.
And by the way - I'd argue that HTML and CSS are not more "forgiving" towards the user, "silently failing" would be a more appropriate definition. I'd rather have an error message saying there's an unclosed tag so the page couldn't be properly rendered rather than the browser trying to infer meaning from broken HTML and misapplying CSS, generating a dadaist poetry piece instead of a blog page.
Unlike typical programs, HTML is often assembled dynamically. This means pages can have broken HTML sometimes, depending on data and context that the developer may not have tested. XML should have been generated from a DOM or something that guarantees proper serialization, but markup-ignorant text-gluing tools are the norm, and they're not capable of ensuring the markup is 100% correct 100% of the time.
These bugs were the worst, because they happened to end users. Users couldn't do anything about unclosed tags or unescaped ampersands, not even notify the developer of the page that refused to display.
Back then HTTPS was rare, but young mobile ISPs loved "optimizing" middleboxes that were messing up the markup. Even if you generated a flawless markup, your pages still wouldn't work for some users. Users were told that your page is bad, and it's your fault, and couldn't contact you about it. ISPs didn't care, because hardly anybody actually used the strict XHTML parsing mode (it made pages inaccessible to IE that had 80% market share). Most "XHTML" pages worked fine thanks to being parsed as regular HTML with invalid extra slashes.
> Without a second browser engine to test pages in, it's really hard to know what is a bug and what is intentional. Devs don't know all the specs by heart. They write whatever happens to work for them, but sometimes they accidentally depend on obscure edge cases in the implementation that were never meant to exist.
I know this isn’t everyone’s experience, but I believe adding IE11 support to my personal website improved the quality of my code.
There were a lot of things I hadn’t specified explicitly, and for whatever reason Chrome/Webkit and Firefox just happened to make the right guesses. IE11 did not, so I had to go back and be clear about exactly what I actually wanted.
Without a second browser engine to test pages in, it's really hard to know what is a bug and what is intentional. Devs don't know all the specs by heart. They write whatever happens to work for them, but sometimes they accidentally depend on obscure edge cases in the implementation that were never meant to exist.
In the long term it's paralysing for the engine maintainers, because any change in implementation could be changing some subtle behavior that breaks some pages. W3C requires two independent implementations, so that they'll share intentional behaviors, but hopefully their bugs will differ.
The single-engine Web will be as fun to maintain as Windows: Windows 11 Explorer has a shiny new context menu with an option to reopen it as an older, uglier context menu, because Microsoft couldn't touch a line of code of the old context menu without breaking apps.