> Now, if no action were taken by browser vendors, the resolution would be simple: the developer would see that the styling on their site was completely broken, and fix it
This assumes the developer sees the output. I remember having a dozen browser builds in the 90s and still getting error reports from users with stuff I never heard of. And back then we didn’t have VMs so I had to keep a bunch of pcs, Macs, etc to test things out.
I think the reason browsers were so lax/supportive is that there were many browsers, servers, etc.
It would be so easy if you could just dev and test your site. But that didn’t work and in fact was kind of a bad approach as you ended up with really tightly wound to a single browser and “works for me” mentality that made users with different configs not use your site, or for intranet made people hate the author for forcing a config and devving in a dumb way (looking at you person who still makes me run ie11 to submit “telework agreements” at my org, you never should have built this to work with ie11 so many years ago).
It seemed like successful sites had to triangulate what the de facto standards are and code in a way that made testing really tough.
That’s why doing the opposite of Postel’s Law is so effective. If your protocol or file format mandates fatal errors instead of being lenient in what you accept, you surface the error immediately during development and stop it from getting into production.
How many HTML or CSS parse errors do you think make it into production?
How many Python, Ruby, Java, Go, or PHP parse errors do you think make it into production?
> It seemed like successful sites had to triangulate what the de facto standards are and code in a way that made testing really tough.
Yes, and this is the consequence of Postel’s Law that the article is arguing against.
Surfacing the error immediately means customers not buying your stuff. Or people not seeing your site.
Personally, I’d rather have some functionality than none.
When you have a really diverse audience with high stakes, being accommodating is valuable. When I have control over the pipeline then I can afford to be strict in surfacing and correcting errors. But when I have 10,000 different users who will not report errors and just move on, I need something else.
> Surfacing the error immediately means customers not buying your stuff. Or people not seeing your site.
No, immediately means when the code is written, not some arbitrary time later in production.
When somebody writes Python, Ruby, Java, Go, or PHP with a parse error, the developer notices immediately because the runtime is conservative in what it accepts and refuses to run it. Fixing the error is mandatory before the code can make it into production where it can affect your customers and make them not buy stuff.
When somebody writes HTML or CSS with a parse error, that can easily make it into production because nothing between the point where the mistake is made and production will refuse to parse it, everything in the chain is lenient in what they accept and pass it along to where your customers can be affected.
Isn’t the point of a protocol is that anyone can write a parser and browser? How would I test immediately in every browser, since there’s so many different things parsing and interpreting and rendering?
The whole point of what we are discussing is to define the protocol to require unambiguous errors instead of lax undefined behaviour. If every parser rejects errors instead of trying to work around them in their own special way, errors are surfaced in the first browser you test with because it won’t be trying to compensate for the error in ways you might not be aware of.
This assumes the developer sees the output. I remember having a dozen browser builds in the 90s and still getting error reports from users with stuff I never heard of. And back then we didn’t have VMs so I had to keep a bunch of pcs, Macs, etc to test things out.
I think the reason browsers were so lax/supportive is that there were many browsers, servers, etc.
It would be so easy if you could just dev and test your site. But that didn’t work and in fact was kind of a bad approach as you ended up with really tightly wound to a single browser and “works for me” mentality that made users with different configs not use your site, or for intranet made people hate the author for forcing a config and devving in a dumb way (looking at you person who still makes me run ie11 to submit “telework agreements” at my org, you never should have built this to work with ie11 so many years ago).
It seemed like successful sites had to triangulate what the de facto standards are and code in a way that made testing really tough.