-Max

PS: If I try to leave a comment with JavaScript disabled, I get a misleading error message.

Page: http://users.skynet.be/mgueury/mozilla/

Sure, if anybody had been required to read the HTML spec, they would have given up. But what you did to learn HTML is what I did, too–copy somebody else’s. If HTML had been strict from the beginning, that copied HTML would be strict and we’d be fine. If we wanted to do something that wasn’t in the original, we could go read the spec or a good, simple reference. This all works fine for Python. It works for almost every templating system I’ve used. I think it would have worked fine for HTML.

My problem with CSS is I think it’s somewhat overengineered, leading to complexities in the design that don’t need to be there, that just layer on top of the complexities and confusions of parsing HTML to create implementations so complex that before we had something like Acid2 (written by one of the few people who actually understands the darn spec–and I am not one of those people) there were no actually compliant implementations.

When nobody can easily create a compliant implementation of a spec, there’s definitely some problem relating to complexity, whether it’s unstrictness or something totally different. Having an un-implementable spec is only slightly better than having no spec, and they both lead to implementation-defined languages, which are disastrous if there’s more than one implementation.

-Max

HTML definitely was successful due to the sloppyness - I remember when I first created a popular public website (early 1994) and if I’d been required to read a book (in 1994!!) or spec on HTML I’d have given up. Instead, I took a look at sun.com and guessed. I sometimes wish that web browsers starting with the earliest Cello’s and Mosaic’s would have alerted the developer to a coding error by highlighting the error in the View Source output - this would have tidied up a lot of the web without having to make HTML parsers strict.

Look at true XHTML parsers - they are required to stop parsing on the first XML error resulting in a cryptic error message to the user. The sloppyness of HTML allows it to carry on processing and give a “best attempt” at rendering.

CSS is just the right amount of sloppyness. And it is successful because of it. Unfortunately, as you say CSS is unable to do things that many designers want - which is why the abomination of the CSS3 Advanced Layouts module has been created. Plus, there is no modularization in HTML styling so CSS tends to have unfortunate global effects where only local effects were intended (CSS block formatting context anyone?).

I’m not aware of a FF extension for validation like that, although it would be a good idea and I’d be surprised if it doesn’t exist.

-Max

So generally, I’d argue that the division, for popularity, is simple/complex than strict/sloppy.

-Max

Is there a good (supporting both HTML and XHTML properly) validator for Firefox, displaying the result briefly in statusbar?

-Max

As far as the mail servers go, I think you’re right to some degree, but coding with strictness does avoid those sorts of problems. Once again, the SMTP RFCs are so complicated in some aspects (and were probably unfortunately un-strict in certain aspects in older editions) that errors like this are possible and now people who receive mail have to account for them. (Processing the received emails suffers from a similar problem.)

In the current environment we have with computers, for the usability reasons that I mention in the article, yes, it’s definitely important to be somewhat liberal with what you receive. But if you’re designing your own protocol, your own language, or something that works only internally to your own system, there’s nothing wrong with being as strict as possible in your own implementation so that you don’t end up being like Email, SMTP, HTML, Perl, etc.

-Max

I once had a mail account at a mail server that checked for compliance with all kinds of RFC’s before accepting a mail (e.g. it called back to the origin domain to see whether it had a valid postmaster@domain account). Many senders happened to use a mailserver with some kind of (small) misconfiguration that prevented their mails from reaching me because of these checks. I complained to the senders and the administrators of their mailservers, but they usually didn’t care or didn’t know what to do about it. In terms of interoperability, this was a pretty bad solution. Of course, if all mail servers did exactly the same RFC checks, the problems would be resolved quickly, but I doubt that all mail server vendors or mail server administrators would spend CPU cycles on stuff like that.

Personally I subscribe to the “be liberal in what you accept, and conservative in what you send” strategy but with the important addition that an implementation should report any errors it detects (e.g. in an error console like the one in Firefox) even if it is able to work around the error. In this way the user can continue using the current version of the software, and the technically savvy user will be aware that there is a problem so that he can report the bug to his software vendor.