Hacker News Reader

Comment by Animats | Hacker News Reader

Yes, that's a good article.

I really hoped that XHTML would win out. Have you ever looked at the HTML5 parsing rules? They codify acceptance of malformed comments and specify standard handling of bad HTML. There are pages of special cases needed just to build a tree from the tags. Check out Python's "html5parser" for the amount of effort required per input character to make this work.

At least in XHTML, the tags balance.

View on HN

What a strange, myopic view that a language should be judged primarily by how easy it is to parse. Writing a parser is something very few will have to do compared to how many will use the language itself. It seems self evident that the language should first be judged on how easily it lets you express what yourself.

Forgiving HTML parsing is one of the great strengths of the web.

http://quandyfactory.com/blog/39/the_virtue_of_forgiving_htm...

The main point of that article is:

> They're missing the point. The virtue of forgiving parsers is that they vastly increase the pool of people able and willing to create web content.

I find it very hard to believe more people are coding because the threshold of what is an error has been relaxed. Although I do admit 'On Error Resume Next' is what kept me motivated to learn programming in VB6.

So I'd say it might be an advantage for getting more people hooked in programming webpages, but professionally the price we pay to have this easy ramp up for beginners is very high.

Really? You think normal people have the patience for the Web browser just excepting out if they forget to close a tag?

Well, my other software development does too actually.

But that's the thing; there are many, many people out there writing HTML who are not programmers. I mean, much of it is a horrifying mess, but it looks more or less correct in a Web browser or an e-mail client and that's what's exciting about it.

"Forgiving parsers" meant people had to learn when to use

    <!--[if IE 6]>
    Special instructions for IE 6 here
    <![endif]-->

While xhtml was nicer to parse, xhtml only described how to render a valid page . How often are pages like that in the wild, even if the page itself is fine some user add on or script can put other stuff in, possibly invalid.

HTML5 described is so complex because it it unlike XML and it's strict validity, HTML5 works with even the most mangled tag soup

For XHTML to win, we'd have to lose our history. Yes, it would have been simpler in terms of parsing, but I'm glad practicality beat purity. Everytime I see a CDATA section in some old code, something inside me dies.

If malformed/ bad HTML must be handled then it is no more bad/malformed, it's a part of the standard.

IMHO plain stupid. Btw there is the same thing for RDF specs on how to handle bad literals and other stuff.

Unfortunately with decades of baggage they can't very well just break things.

Reply on news.ycombinator.com