Comments on: Absent Elements and Validation http://html5doctor.com/absent-elements-and-validation/ helping you implement HTML5 today Thu, 11 Mar 2010 12:49:45 -0800 http://wordpress.org/?v=2.9.2 hourly 1 By: Alohci http://html5doctor.com/absent-elements-and-validation/comment-page-1/#comment-895 Alohci Sun, 30 Aug 2009 21:33:55 +0000 http://html5doctor.com/?p=777#comment-895 Nice article. One quibble however. In my opinion is wrong to characterize Google's use of <!doctype html> as meaning that they are using HTML5. All they are doing is making use of a single piece of information that came out of the research for HTML 5 , which is that <!doctype html> is the fewest number characters that will cause all browsers to use full standards mode. For pages that are famous for not wasting characters, this makes perfect sense, regardless of any version of HTML being targeted. Nice article. One quibble however.

In my opinion is wrong to characterize Google’s use of <!doctype html> as meaning that they are using HTML5. All they are doing is making use of a single piece of information that came out of the research for HTML 5 , which is that <!doctype html> is the fewest number characters that will cause all browsers to use full standards mode. For pages that are famous for not wasting characters, this makes perfect sense, regardless of any version of HTML being targeted.

]]> By: Rich http://html5doctor.com/absent-elements-and-validation/comment-page-1/#comment-882 Rich Thu, 27 Aug 2009 20:42:02 +0000 http://html5doctor.com/?p=777#comment-882 @Rich thanks for the spots, should be corrected now :) @Barney, you make some great points there. I think you're right about Google <q>giving it an HTML5 page and then serving loads of HTML4 is confusing, misleading, and ultimately pointless</q>, but the point being let's illustrate the fact that <em>"implementing"</em> <abbr>HTML</abbr> 5 is that easy. I also think you've summed up your point about doctype validation being subject very well albeit that a few bit's seems to have been stripped from the markup? I'm not sure I follow on the part about IE6 though, if you've applied the javascript shiv (as required by all versions of IE) you can style elements normally thought most will require display:block - or are we at crossed wires? Anyway thanks for your input. Rich @Rich thanks for the spots, should be corrected now :)

@Barney, you make some great points there. I think you’re right about Google giving it an HTML5 page and then serving loads of HTML4 is confusing, misleading, and ultimately pointless, but the point being let’s illustrate the fact that “implementing” HTML 5 is that easy.

I also think you’ve summed up your point about doctype validation being subject very well albeit that a few bit’s seems to have been stripped from the markup?

I’m not sure I follow on the part about IE6 though, if you’ve applied the javascript shiv (as required by all versions of IE) you can style elements normally thought most will require display:block – or are we at crossed wires?

Anyway thanks for your input.

Rich

]]> By: Barney http://html5doctor.com/absent-elements-and-validation/comment-page-1/#comment-871 Barney Tue, 25 Aug 2009 17:47:57 +0000 http://html5doctor.com/?p=777#comment-871 There are some good points helpfully elucidated in this article but the general point and gist of things is a bit unclear, especially as regards your references to Google. The point that Google are confident enough to apply the generic HTML doctype, and that it clearly doesn't break their pages in any tangible ways, should clear up a lot of <abbr title="Fear, Uncertainty and Doubt">FUD</abbr> that people get when it comes to the ultimate value of tick-all-the-boxes validation and the practicalities of user-agent parsing — however the advantages (in fact, any incentive — theoretical or otherwise) are completely missing from the analysis. Telling the browser you're giving it an HTML5 page and then serving loads of HTML4 is confusing, misleading, and ultimately pointless (right?). I disagree that having makes a page de facto HTML5 (and I think you're misinterpreting <a href="http://adactio.com/journal/1595/" rel="nofollow">Jeremy Keith's article on the subject</a>) — what this is saying, literally, is "this is an HTML page of some kind or other but I won't to commit on any further specifics (ie variant, version, strictness)". Google's page says it is HTML, no more, no less, but the actual code could legitimately be described as HTML4.01. It doesn't actually contain any HTML5. In theory (not sure about practice), this vague html doctype might be considered good practice in a template for a huge site with both legacy and bleeding-edge elements that might contain deprecated HTML4 on some pages, and as-yet-unsupported HTML5 on others. But when I say 'good practice', it's only inasmuch that it's better practice than no doctype at all — at least the browser knows it's parsing HTML and not, for instance, an MP3, a PDF or simple TXT — how much better it is than having a single more specific, but often or always incorrect HTML-variant doctype (say, XHTML strict), is a whole other debate. The end impression I get from the article is that since browsers will always interpret HTML and XML as best they can in their own individual ways anyway — and seeing as by-the-book validation ultimately doesn't affect the end user experience — doctype is simply irrelevant. I'm not saying this is horribly misguided or short-sighted, and this isn't a rhetorical criticism. I think there is an important statement that could sum up this article: In practice, doctype validation is subjective. But I also think that's meaningless without elaboration into a few sub-points: 1) doctypes have no intrinsic value — it's their interpretation by the user agent(s) that counts. 2) Accurate specificity in the doctype means less guess-work on the user agent end, which means that if used correctly up to the browser's understanding, it will be able to start rendering immediately without first processing the content and working out <em>how</em> it should process it. FF3 will render my element whether I tell it upfront I am serving HTML5 or not, just as IE8 won't render it with just as much attention paid to the doctype — whatever it may be. 3) A document that fails w3 validation is not necessarily a bad thing, but a document that browsers have difficulty rendering, or render differently, is. Just as we currently wrap s inside s for Flash that will end up with at least some of the code being unrenderable and hence ignored by the browser, so should users using elements put alternative content within the tags if they want the vast majority of users to get any content in that part of the document (and if you want IE6 users to see your page as you intend, don't rely on CSS rules applied to HTML5-spec elements). Sorry to bang on a bit, but I think the topic's well worth the debate. There are some good points helpfully elucidated in this article but the general point and gist of things is a bit unclear, especially as regards your references to Google.

The point that Google are confident enough to apply the generic HTML doctype, and that it clearly doesn’t break their pages in any tangible ways, should clear up a lot of FUD that people get when it comes to the ultimate value of tick-all-the-boxes validation and the practicalities of user-agent parsing — however the advantages (in fact, any incentive — theoretical or otherwise) are completely missing from the analysis. Telling the browser you’re giving it an HTML5 page and then serving loads of HTML4 is confusing, misleading, and ultimately pointless (right?).

I disagree that having makes a page de facto HTML5 (and I think you’re misinterpreting Jeremy Keith’s article on the subject) — what this is saying, literally, is “this is an HTML page of some kind or other but I won’t to commit on any further specifics (ie variant, version, strictness)”. Google’s page says it is HTML, no more, no less, but the actual code could legitimately be described as HTML4.01. It doesn’t actually contain any HTML5.

In theory (not sure about practice), this vague html doctype might be considered good practice in a template for a huge site with both legacy and bleeding-edge elements that might contain deprecated HTML4 on some pages, and as-yet-unsupported HTML5 on others. But when I say ‘good practice’, it’s only inasmuch that it’s better practice than no doctype at all — at least the browser knows it’s parsing HTML and not, for instance, an MP3, a PDF or simple TXT — how much better it is than having a single more specific, but often or always incorrect HTML-variant doctype (say, XHTML strict), is a whole other debate.

The end impression I get from the article is that since browsers will always interpret HTML and XML as best they can in their own individual ways anyway — and seeing as by-the-book validation ultimately doesn’t affect the end user experience — doctype is simply irrelevant. I’m not saying this is horribly misguided or short-sighted, and this isn’t a rhetorical criticism.

I think there is an important statement that could sum up this article:

In practice, doctype validation is subjective.

But I also think that’s meaningless without elaboration into a few sub-points:

1) doctypes have no intrinsic value — it’s their interpretation by the user agent(s) that counts.

2) Accurate specificity in the doctype means less guess-work on the user agent end, which means that if used correctly up to the browser’s understanding, it will be able to start rendering immediately without first processing the content and working out how it should process it. FF3 will render my element whether I tell it upfront I am serving HTML5 or not, just as IE8 won’t render it with just as much attention paid to the doctype — whatever it may be.

3) A document that fails w3 validation is not necessarily a bad thing, but a document that browsers have difficulty rendering, or render differently, is. Just as we currently wrap s inside s for Flash that will end up with at least some of the code being unrenderable and hence ignored by the browser, so should users using elements put alternative content within the tags if they want the vast majority of users to get any content in that part of the document (and if you want IE6 users to see your page as you intend, don’t rely on CSS rules applied to HTML5-spec elements).

Sorry to bang on a bit, but I think the topic’s well worth the debate.

]]> By: Rich http://html5doctor.com/absent-elements-and-validation/comment-page-1/#comment-870 Rich Tue, 25 Aug 2009 16:18:02 +0000 http://html5doctor.com/?p=777#comment-870 Just a couple of errors: "What affect will this have for backwards compatibility?" -> effect, not affect "but to all intense and purpose" -> intents, not intense Good article - the point is that you may as well use HTML5 where possible, as the doctype doesn't really affect how browsers work (other than quirks mode). Most of the deprecations are pretty trivial anyway, all have obvious ways to replace them using either more appropriate elements, or CSS. Just a couple of errors:

“What affect will this have for backwards compatibility?” -> effect, not affect

“but to all intense and purpose” -> intents, not intense

Good article – the point is that you may as well use HTML5 where possible, as the doctype doesn’t really affect how browsers work (other than quirks mode).

Most of the deprecations are pretty trivial anyway, all have obvious ways to replace them using either more appropriate elements, or CSS.

]]>