This entr […]

This is a pity that major browser vendors, at least open-source ones if not all, and standard consortium are not able to set up and agree on clear guidelines and validation process.

Why do we make a DTD declaration if the browsers only look at the MIME type from the server? That is, to be honest, very stupid! I’m puzzled, I’m amazed, I’m out of words… almost.

1: It would make sense to me, it the browser looked at the MIME type as a ‘do this qualify as something I can process at ALL’ and then it looked at the DTD to know the REAL content.
Remember, the MIME type from the server is File Extention Based! The you REALLY think all webpages will now get a .xml extention so it can be served as text/xml and understood by the browser?

2: If the above is to be (.xml file endings = text/xml) how is the browser able to verify the Type of XML, and parse it? According to this article, browsers don’t read and don’t care about the DTD!

3: May I be s bold as to suggest that browsers take the MIME type from the server ‘with a grain of salt’ and only use it as a guideline, and then looks at the DTD to determin the actual document type?

Ohh, and may I be so bold (sorry it’s late here) to note that I think it sily to Require an explicit tag close () if the tag is self-containing! Why the …. should I make a if all that is needed is ?
To me, it seems as all those people making up the standards are on 100+MBit connections to servers that are next door, and they don’t care about bandwidth. So you say “what’s that extra 6 letters gonna matter? Well, in a simpe page, with a few of these tags, it’s quickly 1000 letters, easily doubling the size of the page served!

I understand it’s nice to be able to make content in the Canvas tag for browsers that don’t render it, but if _I_ as a deveoper decide that there should NOT de such content, why do I HAVE to make the extra tag?

PS: Does this also mean that Script includes in the Header section of a page should have the tag ? If so, this is outright STUPID. Why does script need it, when META or LINK does not????????????

Someone should stop smoking that grass…. 😉

This leads to the following validator warnings:

When the language is declared on an element:

if the doctype is set to one of the XHTML1 doctypes the author will see errors for each ‘lang’ attribute because that attribute is not defined in the XHTML1 schema.
if the doctype is set to one of the HTML4.01 doctypes the author will see errors for each ‘xml:lang’ attribute because that attribute is not defined in the HTML4.01 schema.

regardless of doctype setting both ‘name’ and ‘id’ attributes to the same value (of type ID) is technically wrong, but I doubt any validator will catch that anyway.
the slash in self-closing tags is technically incorrect but most validators have been updated to overlook that issue

None of this is cause for alarm. This merely requires authors to be sentient beings who are made aware of these validation warnings and understand that they can safely ignore them. If I’m wrong about that and there are some practical consequences to ignoring those warnings in one browser or another please let us know.

There may be other issues that authors should be made aware of. For eample:

To ensure one stays out of quirksmode (in IE) I believe one should also leave off the xml declaration (so that means one has to stick with xml 1.0 and utf-8 or utf-16 encoding).
When using the DOM avoid DOM level-0 and check for the availability of the namespace methods/functions and call the appropriate method whether the document is served as application/xhtml+xml or text/html. I’m not suggesting the same document be served concurrently as both types, but rather providing suggestions for forward-looking authors to be ready to make the transition with ease and agility.

So if we return to the possible courses of action for serving the resulting XHTML 1 document (authored according to Appendix C guidelines), the outcome depends on the needs of the authors, sites and implementations in question.

Only one of those approaches may be ill-advised under typical circumstances: that of serving text/html to IE and serving application/xhtml+xml to everything else. Mozilla folks discourage this except under special circumstances and I think they provide good reasons.
Serving the document as text/html. This is perfectly acceptable under W3C guidelines. Many authors want to know that it’s OK to focus only on XHTML. It is, and Appendix C (along with advice from places like Surfin’ Safari) should show them the way. Change merely the doctype, if you wish, on an Appendix C authored page from XHTML1 to HTML4.01 and that’s all (if even that; you could just leave the doctype set to XHTML1 and I am unaware of any practical negative implications)
serving as application/xhtml+xml and leave older and browsers and IE 6 and 7 behind. This may be a perfectly reasonable response for many sites. I think the WebKit site could take that approach with almost no negative implications. Others could do so in similar situations. Just like the old frames days add the following code for IE:
This site uses XHTML. If you’re using an out-of-date browser please download one of the many free browsers: (and then present a list of browsers)
Stick with HTML 4.. Why when XHTML 1 works fine as a substitute. Plus as authors were originally told (and correctly) authoring in XHTML 1 prepares them for the future? The introduction of XML and XHTML has alredy improved the quality of HTML authroing tools and the quality of HTML when hand-coded. Following XHTMl syntax is just easier for most folks. Moving from ‘lang’ to ‘xml:lang’ and ‘name’ to ‘id’ shouldn’t be that big of a deal either.

One other approach left out of the discussion would be to use application/xml or text/xml and then one may also support IE7 with pure XHTML.

The point is authors need to know there’s a difference in the way browsers handle mime types. If that’s what this article wants to say I’m 110% behind you. If you’re trying to say what other misguided (some cited here) have said that there’s something wrong with serving HTML compatible XHTML as text/html, that’s where we part ways. Is that a matter of opinion? Yes. Except I like my opinions backed up by reasoned argument. I don’t see that in this post or in a couple of those sites you cite.