Hacker News Reader

Comment by jimmyjazz14 | Hacker News Reader

I would prefer that the parser just failed when invalid code was encountered, personally I saw this as a strong point of XHTML.

View on HN

One of the nice things about the web is that all websites still work. Here is the first webpage: http://www.w3.org/History/19921103-hypertext/hypertext/WWW/T... That one wouldn’t work with a strict parser (look at the source: it uses the header tag instead of the head tag).

Breaking half or more of all the websites out there wouldn’t exactly be what I would call the “spirit of the www”.

Use a new parser for new pages, the old parser for old pages. The introduction of H.264 didn't suddenly render all older formats unplayable. Why can't a new markup format coexist with older formats, too?

What would be the advantage of that? Also, you then never truly can ditch the old parser if you want to keep everything working. Your browser has to come with two parsers for all eternity.

How many codecs does your media player come with?

Not enough because there always seems to be this one file it absolutely cannot play ;)

It’s possible to do it but it’s also needlessly complex while giving you very little in return. The biggest, most problematic flaw of allowing browsers to parse invalid code, namely that different browsers might handle failure differently, is in the process of being fixed and that’s good enough, I think.

Strict parsing has been tried and it was a resounding failure. It’s not going to happen.

1. How do you discriminate?

2. What would the point be, apart from annoying every single end user?

Maybe a content-type header from the server? The point as I may wrongly see it is, that attempting to support backward compatibility indefinitely will result in overly complex and bloated browsers in the future.

Nobody sets headers and meta information correctly anyway. Those headers cannot be trusted, and browsers have to guess what content-type and character encoding should actually apply to any particular document.

Web browsers already have this, and it sucks. There's XML mode, HTML standards mode, HTML quirks mode and HTML almost standards mode. It's horrible to test and maintain.

You have to realize that what you are proposing is simply a bad idea, even if everything is trying to be pure and perfect:

http://diveintomark.org/archives/2004/01/14/thought_experime...

I think that article may have seriously changed my mind.

You can still write the HTML5 vocabulary as XHTML if you really want to. That's perfectly valid, and defined in the spec.

The HTML5 parsing algorithm is what the browser vendors want and need, however. Since HTML was never specified properly - not even in HTML4, where large areas were just undefined - HTML parsers have slowly evolved through trial and error. If big sites depend on a particular behaviour in a particular browser, other browsers have tried to be bug-compatible with that browser. Browsers that failed to do so have lost market share. If a browser decided to halt on encountering anything invalid would lose all of its users instantly, since the vast majority of documents are invalid.

Parsers have slowly converged towards each other, and the HTML5 algorithm is the compromise between them that breaks the last amount of content.

In other words, the goal of the HTML5 parsing spec was never to make something nice and clean. The goal was to define how to parse the unholy mess all you web developers out there have created during the past two decades. A clear spec, a good test suite and exactly identical behaviour between browsers is a benefit for everyone.

I agree. But: Why do we need exactly identical behaviour? Wasn't HTML intended to leave lots of discretion for rendering decisions to the browser?

If you parse a string of bytes, it's nice if it always turns into the same DOM. That's the scope of the HTML5 parser. There is no benefit to inconsistencies here.

Allowing browsers on different platforms to adjust page widths, font sizes, whether or not load images and plugins in accordance with the user's preferences is fine, but that's an entirely different issue.

Thanks for the clarification.

Hmmm. I suspect that would break 90% of web pages on the web. On the other hand, people would make their pages valid pretty quick. :-)

What about pages that are not maintained but still carry value?

No. Browsers that implemented this would just lose their market share instantly. Users prefer being able to use their favourite sites.

Reply on news.ycombinator.com