5 ms·

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

benhoyt 16y ago
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. :-)
- wlievens 16y ago
  What about pages that are not maintained but still carry value?
  - deleted 16y ago
    [deleted]
- wilhelm 16y ago
  No. Browsers that implemented this would just lose their market share instantly. Users prefer being able to use their favourite sites.
ugh 16y ago
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/TheProject.html 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”.
- tedunangst 16y ago
  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?
  - ugh 16y ago
    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.
    - philwelch 16y ago
      How many codecs does your media player come with?
      - ugh 16y ago
        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.
  - masklinn 16y ago
    1. How do you discriminate? 2. What would the point be, apart from annoying every single end user?
    - jimmyjazz14 16y ago
      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.
      - wilhelm 16y ago
        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.
haberman 16y ago
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_experiment http://diveintomark.org/archives/2004/01/14/thought_experime...
- jimmyjazz14 16y ago
  I think that article may have seriously changed my mind.
wilhelm 16y ago
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.
- eru 16y ago
  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?
  - wilhelm 16y ago
    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.
    - eru 16y ago
      Thanks for the clarification.

benhoyt 16y ago

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. :-)

wlievens 16y ago
What about pages that are not maintained but still carry value?
- deleted 16y ago
  [deleted]
wilhelm 16y ago
No. Browsers that implemented this would just lose their market share instantly. Users prefer being able to use their favourite sites.

ugh 16y ago

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/TheProject.html 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”.

tedunangst 16y ago
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?
- ugh 16y ago
  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.
  - philwelch 16y ago
    How many codecs does your media player come with?
    - ugh 16y ago
      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.
- masklinn 16y ago
  1. How do you discriminate? 2. What would the point be, apart from annoying every single end user?
  - jimmyjazz14 16y ago
    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.
    - wilhelm 16y ago
      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.

haberman 16y ago

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_experiment http://diveintomark.org/archives/2004/01/14/thought_experime...

jimmyjazz14 16y ago
I think that article may have seriously changed my mind.

wilhelm 16y ago

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.

eru 16y ago
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?
- wilhelm 16y ago
  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.
  - eru 16y ago
    Thanks for the clarification.