6 ms·

I really hate when my code doesn't compile. If my code is wrong, the compiler should just figure out what to do.

possibilistic 12y ago
You hit the nail on the head. HTML5 got one thing right though: standardization of the DOM failure behavior. As an implementation detail of their design, they went with "sensible recovery" for failures over stricter failure modes. In going with the WHATWG over the W3C, we ultimately chose "easy to author, (slow to evolve) living standard" over "strictly typed yet developer extensible". I was disappointed, but it's good for some parties I suppose. (It certainly keeps the browser vendors in charge of the core tech...) The W3C over-engineered to a fault. They had a lot of the right ideas, but were too enamored by XML and RDF.
- yuhong 12y ago
  HTML5 got one thing right though: standardization of the DOM failure behavior. As an implementation detail of their design, they went with "sensible recovery" for failures over stricter failure modes. It was browsers that did that in the first place. HTML5 just standardized the exact behavior on failures.
  - possibilistic 12y ago
    Which is what I said, right? HTML 4 - vendors implemented the spec incongruently and failed in their own special ways. XHTML strict - standard parsing rules with strict failure mode. HTML 5 - standard parsing rules, suggested (but not required) rendering behavior for browser uniformity, and well-defined failure behavior.
  - domenicd 12y ago
    Incorrect. HTML5 synthesized the exact behavior that was closest to the majority of browsers. But not all browsers agreed (e.g. Mozilla would change its HTML parsing behavior depending on network packet boundaries), so there was still effort aligning with the newly-specced common parsing algorithm. At the time there was much skepticism that such alignment was even possible.
    - TheLoneWolfling 12y ago
      > Mozilla would change its HTML parsing behavior depending on network packet boundaries I want to know more...
      - domenicd 12y ago
        Some links: https://blog.mozilla.org/mrbkap/2013/08/12/the-old-html-parser-is-dead-long-live-the-html-parser/ https://blog.mozilla.org/mrbkap/2013/08/12/the-old-html-pars... http://ln.hixie.ch/?start=1138169545&count=1 http://ln.hixie.ch/?start=1138169545&count=1 https://bugzilla.mozilla.org/show_bug.cgi?id=324875 https://bugzilla.mozilla.org/show_bug.cgi?id=324875
- domenicd 12y ago
  It wasn't really a choice in favor of "easier to author." It was a choice in favor of "will this actually get implemented, or just be fancy theorycraft?" No browser vendor was going to ship new features only in XML parsing mode, because that was author-hostile enough that it would lose them authors, and thus users. (Browser game theory.) The choice of HTML over XML syntax was purely practical, in this sense.
lutusp 12y ago
> I really hate when my code doesn't compile. If my code is wrong, the compiler should just figure out what to do. There's something you're overlooking in the above. If a compiler was smart enough to know what to do with your erroneous code and compile in spite of the errors, that would be the end of programming and programmers.
- wtetzner 12y ago
  I'm pretty sure that comment was sarcasm. It's a complaint about how HTML5 isn't just specified to fail on bad input, but instead gives rules on how to recover.
- eru 12y ago
  And that would be a good thing!
  - lutusp 12y ago
    Well .... now that you mention it ... yes, it would. :)
johnlbevan2 12y ago
Sarcasm? I can't tell anymore :/ I love it when my code doesn't compile (i.e. if I've made a mistake). Much worse if when something tries to be "intelligent" and makes my code do something I never asked for - then I spend hours trying to figure out what the issue is (assuming I've noticed) rather than seeing that I made a mistake and fixing it.
- insertnickname 12y ago
  Yes, I was being sarcastic. Web designers should stop whining and write proper markup code.
  - tolmasky 12y ago
    The problem has nothing to do with web devs but rather that no one wants to use a browser that spits out "error 5" on malformed HTML, which is necessarily what you're implying. The other option is to do your best with the bad HTML, and now we're right back where we started, regardless of how "strict" you make the rules.

You hit the nail on the head. HTML5 got one thing right though: standardization of the DOM failure behavior. As an implementation detail of their design, they went with "sensible recovery" for failures over stricter failure modes. In going with the WHATWG over the W3C, we ultimately chose "easy to author, (slow to evolve) living standard" over "strictly typed yet developer extensible". I was disappointed, but it's good for some parties I suppose. (It certainly keeps the browser vendors in charge of the core tech...) The W3C over-engineered to a fault. They had a lot of the right ideas, but were too enamored by XML and RDF.

yuhong 12y ago
HTML5 got one thing right though: standardization of the DOM failure behavior. As an implementation detail of their design, they went with "sensible recovery" for failures over stricter failure modes. It was browsers that did that in the first place. HTML5 just standardized the exact behavior on failures.
- possibilistic 12y ago
  Which is what I said, right? HTML 4 - vendors implemented the spec incongruently and failed in their own special ways. XHTML strict - standard parsing rules with strict failure mode. HTML 5 - standard parsing rules, suggested (but not required) rendering behavior for browser uniformity, and well-defined failure behavior.
- domenicd 12y ago
  Incorrect. HTML5 synthesized the exact behavior that was closest to the majority of browsers. But not all browsers agreed (e.g. Mozilla would change its HTML parsing behavior depending on network packet boundaries), so there was still effort aligning with the newly-specced common parsing algorithm. At the time there was much skepticism that such alignment was even possible.
  - TheLoneWolfling 12y ago
    > Mozilla would change its HTML parsing behavior depending on network packet boundaries I want to know more...
    - domenicd 12y ago
      Some links: https://blog.mozilla.org/mrbkap/2013/08/12/the-old-html-parser-is-dead-long-live-the-html-parser/ https://blog.mozilla.org/mrbkap/2013/08/12/the-old-html-pars... http://ln.hixie.ch/?start=1138169545&count=1 http://ln.hixie.ch/?start=1138169545&count=1 https://bugzilla.mozilla.org/show_bug.cgi?id=324875 https://bugzilla.mozilla.org/show_bug.cgi?id=324875
domenicd 12y ago
It wasn't really a choice in favor of "easier to author." It was a choice in favor of "will this actually get implemented, or just be fancy theorycraft?" No browser vendor was going to ship new features only in XML parsing mode, because that was author-hostile enough that it would lose them authors, and thus users. (Browser game theory.) The choice of HTML over XML syntax was purely practical, in this sense.

lutusp 12y ago

> I really hate when my code doesn't compile. If my code is wrong, the compiler should just figure out what to do. There's something you're overlooking in the above. If a compiler was smart enough to know what to do with your erroneous code and compile in spite of the errors, that would be the end of programming and programmers.

wtetzner 12y ago
I'm pretty sure that comment was sarcasm. It's a complaint about how HTML5 isn't just specified to fail on bad input, but instead gives rules on how to recover.
eru 12y ago
And that would be a good thing!
- lutusp 12y ago
  Well .... now that you mention it ... yes, it would. :)

johnlbevan2 12y ago

Sarcasm? I can't tell anymore :/ I love it when my code doesn't compile (i.e. if I've made a mistake). Much worse if when something tries to be "intelligent" and makes my code do something I never asked for - then I spend hours trying to figure out what the issue is (assuming I've noticed) rather than seeing that I made a mistake and fixing it.

insertnickname 12y ago
Yes, I was being sarcastic. Web designers should stop whining and write proper markup code.
- tolmasky 12y ago
  The problem has nothing to do with web devs but rather that no one wants to use a browser that spits out "error 5" on malformed HTML, which is necessarily what you're implying. The other option is to do your best with the bad HTML, and now we're right back where we started, regardless of how "strict" you make the rules.