Hacker News Reader

Comment by Too | Hacker News Reader

This is why I'm against the commonly praised "Be conservative in what you send, be liberal in what you accept" principle. Being liberal in what you accept only gives you compatibility nightmares in the future. Another perfect example of this is html and is the reason why every browser has to reimplement all the bugs of internet explorer 6 in order to not "break the internet". Really, why should a browser try to correct a corrupt document with trailing tags and open attributes. Beginner developers/designers will simply think "looks good on my machine, deploy and forget" and then we are stuck supporting that kind of corruptness forever.

View on HN

I'd even go as far as to suggest the opposite "be liberal in what you send [1], be conservative in what you accept (and fail as noisily as possible)".

[1]: by this I mean that it's ok if your "liberal" output (by "liberal" I usually mean "assuming newer features not yet widely adopted in other apps it needs to talk with") forces the user to upgrade other components to the latest versions in order to use yours, because if you're in a choice of "f_g the downstream guys" or "making trouble for the upstream guys", you should always choose "f_g the downstream guys", because here "f_g" them only means the minor inconvenience of forcing them to upgrade to decent versions and moves everything forward in the process, and has the added side effect of forcing them to also do their damn security upgrades :)

The way to know which principle you should follow is to ask yourself: am I in the position to set a de facto standard?

If you are, then be conservative in what you accept, and prevent whole categories of problems in the future.

If you're not, then it's too late for that. The damage is already done. Be liberal in what you accept, and try to mitigate the resulting harm.

"But, of course, if that had happened, maybe the web would never have taken off like it did, and maybe instead, we’d all be using a gigantic Lotus Notes network operated by AT&T. Shudder."

http://www.joelonsoftware.com/items/2008/03/17.html

You must be my doppelganger, because I've been saying exactly this for some time. Internet Explorer caused so much trouble partly because it accepted so much bad HTML. It would close tags for you, even.

The automatic tag closing behaviour is even specified now.

But look at it another way: imagine browsers accepted only valid HTML and every browser had some bugs in what they consider valid. Writing a document in a way that it displays at all might be a challenge already then. Add to that that not everyone is on the latest browser version (that was probably more true in the 90s as well) and you get all the current pains just with worse symptoms. I'm not really sure that's better.

I may be wrong here, but isn't implicit tag closing consequence of html deriving from sgml? mandatory tag closing is something that came with xml AFAIK

Yes, but then nobody implemented the SGML definition of HTML correctly. According to the standard, browsers should have parsed

    <a href=foo/bar/baz>qux</a>

    <a href="foo">bar</a>baz>qux</a>

since it did not only include optional closing tags, but also short tags. (This is incidentally why several SGML-based HTML validators used to complain about "end tag for element A which is not open" in the presence of href attributes without quotes.)

IE didn't start that, it had to accept that shit because everything else did long before it. I'm not even sure what browser started it. I'm positive that the first graphical browser I used (Cello) did, though.

I'm not even sure it was really considered a bad thing at the time.

Have a look at the paragraph (and list) section(s) of:

http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt

   P: Paragraph mark

     The empty P element indicates a paragraph break.
     The exact rendering of this (indentation,
     leading, etc) is not defined here, and may be a
     function of other tags, style sheets etc.

To whit, the well-formed, "good" example:

    <h1>What to do</h1>
    This is a one paragraph.< p >This is a second.
    < P >
    This is a third.

Yes, with spaces and alternating case. This was the standard before IE6 came out, so it's not that crazy that they closed up some bold and italics tags -- I'm not entirely sure if there were (are?) any other SGML dialects that were quite as loosely defined as early "HTML" was.

I think IE6 did a lot of awful things, but the only real "damage" done was in borking the CSS implementation (especially the box model). The fact that it rendered crap HTML sort-of-ok wasn't all that bad.

It was the crazy things it did with, lets say.... specially crafted HTML that led to a lot of problems. And MS FrontPage's insisting on adding COLOUR="#000000" (black) to all documents, and assuming BACKGROUND was set to white did a lot to break semantic mark-up.

Oh yeah, I'm not saying IE6 didn't do a lot wrong, just that this wasn't one of them.

But I also think it's worth remembering that IE5/6 also featured a lot of early experiments in things that are now considered essential components in the web. XMLHttpRequest was a huge advancement, and while ActiveX was obviously crappy it was at least part of an attempt at creating a more dynamic web.

IETF groups continue to perpetuate this junk, too. It opens up security holes, as you can end up with a "confused deputy" situation. A proxy might read certain header fields one way because the spec encourages the proxy to "infer" the "meaning" of creative headers. But a server behind the proxy might interpret things differently.

Reply on news.ycombinator.com