.foo {
someprop: boring-old-value;
someprop: awesome-new-value;
}
Getting underneath the patterns and anti-patterns of permissiveness in an informed way is a lot more useful IMO than the knee-jerk reaction of declaring all permissiveness harmful and running away. Especially in light of the web's incredible wins via this strategy.
But these are pretty damn twisted priorities. A little bit of social responsibility wouldn't hurt.
Not following Postel's law would result in brittle system components that break when other parts of the system evolve.
Being liberal in what you accept is precisely the definition of brittle: if there's an update that reduces the set of representable input data, but you keep the code that processes the user's input into data, then an untested, little-used edge case could invalidate your assumptions about the rest of the system.
This depends how much graceful degradation you have available to you. In systems/domains where little is available, following Postel's law can result in silent failures rather than explicit/loud ones. The question isn't whether they break or how brittle they are, but whether you will notice whether they did break. Each system exists within a range on a continuum of how acceptable Postel's law is.
Basically, give people a hand, and they'll grab your whole arm. It's human nature, and Web developers aren't above it.
Also, there's no need to crash the tab. The browser could simply stop running any JavaScript, and leave the user with a static page.
https://tools.ietf.org/html/rfc793
2.10. Robustness Principle
TCP implementations will follow a general principle of robustness: be
conservative in what you do, be liberal in what you accept from
others.How are you going to enforce this for everyone?
> TCP implementations will follow a general principle of robustness (...)
This rule has worked well for TCP implementors in large part because of their circumstances, which are very different from those of browser implementors and Web developers:
(0) Priorities: How much do the following desiderata matter to each group: reliability, performance, new features?
(1) Skill: What skills does a representative programmer from each group have?
(2) Risk profile: How does each group cope with the possibility of design and implementation errors? How much technical debt are they willing to take?
I'd contend that Postel's law doesn't scale beyond relatively small groups of highly skilled programmers, for whom reliability is paramount and trumps all other considerations.
What's the current market share for IE? 30% 40%? That seems pretty good for a browser which for years was a broken malware propagating mess.
Imagine what C++ would look like if all compilers had to accept all different variations of it, and the result of compiling 100 almost valid C++ files should, as far as possible, be a program that runs in some sense.
Most of the web pages I have ever written have probably been ill-formed because browsers don't tell me what's wrong, and instead show me a (nearly) working web page.
C++ is still a lot more permissive than it could and should be.
> Most of the web pages I have ever written have probably been ill-formed because browsers don't tell me what's wrong, and instead show me a (nearly) working web page.
Same here. The idea that JavaScript ought to be permissive and forgiving because its target audience doesn't know what they're doing turned out to be a self-fulfilling prophecy on the part of its designers.
Of course. If you served XHTML properly (by setting "application/xhtml+xml" MIME type), ill-formed XHTML would just show you a big syntax error instead of the page. Try it, that's still the case.
Even when being well-formed, lots of sites still used "text/html" type to trigger HTML (SGML) parser instead of XML one, as any 3rd party code embedded into the website would of course crash the page as well.
That was one of the reasons why XHTML never got popular and eventually has been abandoned.
However, this MIME type was extremely rare because MSIE would not show a web page unless the MIME type was text/html.
Furthermore, the extreme brittleness of XHTML was generally regarded as a Bad Move as one single URL in your source code with a literal ampersand instead of & would cause a complete and total breakage of your web page. Of course, many web pages are crummily concatenated strings and there are a lot of web devs who would never be able to reliably generate 100% XHTML-compliant output. Shit, pasting in a snippet of HTML where the BR tags omitted the self-closing slash would break your XHTML validation.
tl;dr: Yes, and it sucked