Are there any pros to use HTML 4.01 strict over XHTML 1.0 strict (content=”text/html)?
Are there any pros to use HTML 4.01 strict over XHTML 1.0 strict (content=text/html)?
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Are there any pros to use HTML 4.01 strict over XHTML 1.0 strict (content=”text/html)?
Sure. Your code will be smaller, since you don’t need to include the extra
"characters on one-word attributes,/characters on self-closing elements, you can leave out various opening and closing tags, such as</p>,</li>, and even<html>,<head>,<body>, and so on are optional in HTML 4.01 (and HTML5). See Optimizing HTML and Optimizing Optimizing HTML for a few tips on stripping down your HTML; many of these pieces of advice work only in HTML 4.01 or HTML5.Now, not everyone needs to minify this much; but if you do, using HTML 4.01 (or HTML5) instead of XHTML can be beneficial.
Also, Internet Explorer doesn’t actually support XHTML as XHTML; if you send it as
application/xhtml+xml, it will just try to download it. So, if you use XHTML, you need to send it to IE astext/html, which will make the browsers just interpret it as HTML. For a somewhat outdated discussion of why XHTML is a bad idea, see XHTML Considered Harmful by Ian Hickson, the current editor of the HTML5 specification (some of these reasons are still valid, some of them are no longer relevant).Here are a few examples:
application/xhtml+xmltext/htmlapplication/xhtml+xmltext/htmltext/htmlNote that the first does not work in IE. The second works in all browsers, but you are just wasting bytes; the browsers don’t interpret namespaces properly, for example, so if you include XML in another namespace, it won’t actually appear in another namespace in your scripts or CSS. The third will display a big error message, and the fourth will display just fine even though it’s not well-formed XHTML (which demonstrates that the browsers are using their HTML parsers).
You can get the exact same effect as the
text/htmlexamples by using an HTML 4.01 doctype, or an HTML5 doctype, as demonstrated in the fifth example (this is also valid HTML 4.01 if you stick the HTML 4.01 doctype into it). If you use HTML 4.01 or HTML5, you can save a lot of space, and you won’t be fooling yourself by sometimes processing the document as XHTML and sometimes processing it HTML.Another reason to beware of serving XHTML as
text/htmlis that it’s processed differently depending on whether it’s parsed by an HTML parser or an XML parser. For instance, a self-closingscripttag, such as<script type="text/javascript" src="foo.js"/>, is valid in XHTML, and if parsed by an XML parser, will be parsed as an empty element. In HTML, however, this will be seen simply as a script opening tag, and it will “eat” the rest of the document, as the parser keeps parsing assuming it’s inside a script until it finds a close tag. This is likely not what you want, and can trip you up if you sometimes treat a document as XML and sometimes treat it as HTML. Here’s an example of this problem; these two documents display differently in Firefox, even though they have the same contents (Safari appears to treat them the same, so this extent of this problem varies between different browsers):<script/>tag in XHTML served asapplication/xhtml+xml<script/>tag in XHTML served astext/htmlThis is not the only difference between the HTML and XHTML parsers. In HTML, a
<table>will have a<tbody>inserted into the DOM implicitly even if you don’t have one in the source; in XHTML, if you don’t specify a<tbody>explicitly, it will not be present in the DOM.So, serving XHTML as
text/htmlwill make your code larger than it would be if you just used HTML 4.01 or HTML5, and it can lead to confusion if you sometimes process it as real XML and sometimes treat it as HTML.