zlacker

> there's still a problem of "bug-compatibility"

They aren't even bugs. The spec allows for interpretations.

>>threes+(OP)
Sounds like there needs to be a new, unambiguous spec.

>>threes+(OP)
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.

>>pmoria+u2
In the case of HTML, that was called XHTML, and it never took off because users need their browser to be forgiving, whether they know it or not.

>>colejo+UF1
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.

>>noisym+rL1
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.