Content-Style-Type is not necessary unless you use style attributes in your markup. A modern document should use external CSS style sheets or, at worst, a style element in the document head.
Content-Script-Type is not necessary unless you use event attributes (such as onclick) in your markup. A modern document should use external unobtrusive scripts.
Hmm… Perhaps I misinterpreted what those are for. I suppose they are only useful when you use inline styles and event handlers, since you should specify the type attribute on style, link, and script elements anyway. It’s ironic that most people who use inline styles and event handlers probably don’t include those meta elements or use the equivalent HTTP headers.
Really, if you send the right HTTP headers and you don’t want to specify keywords for the page a give it a description, you don’t need any meta elements at all.
I definitely agree with you, Tommy, that we should avoid using inline styles and avoid using inline event handlers by making use of modern unobtrusive JavaScript techniques.
Providing HTTP equivalents (for encoding and, where applicable, style and script types) in META elements has its uses. They can be applied when the document is saved to the hard-drive and then viewed locally, i.e., with no HTTP server to send proper headers.
User agents are not required to pay attention to those equivalents, though.
True. That’s why it’s highly recommended that all documents use the Content-Type meta element.
Started reading this thread and at the end it became very very confusing.
Can anyone pl post a small example of a TRUE xHTML 1.1 document (application/xhtml+xml) and another of a TRUE XML based document (application/xhtml+xml) ?
I thought this was a true xHTML 1.1 doc but it seems it isn’t.
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" dir="ltr">
<head>
<title>Test</title>
<meta http-equiv="Content-Type" content="application/xhtml+xml;"/>
</head>
<body>
<div>
Text
</div>
</body>
</html>
The media type (a.k.a. content type, a.k.a. MIME type) must be sent as a proper HTTP header by the server. The user agent needs to know the content type before it receives a single byte of the document.
And so I inserted this at the beginning.
<?php
header('Content-type: application/xhtml+xml');
header("Cache-Control: must-revalidate");
?>
And it works (displays) in IE7 and FF2.
I changed
<div>Text</div>
to
<div>Text<div>
which is wrong and FF shows
XML Parsing Error: mismatched tag. Expected: </div>.
Location: http://localhost/test/test-2.htm
Line Number 12, Column 3:</body>
--^
This wont come up if header(‘Content-type: application/xhtml+xml’); isnt given.
Ofcourse IE7 isn’t showing any error, but it doesn’t seem to be treating it like generic XML.
Edit: I just wanted to know what error are we supposed to be expecting in IE ? Or has version 7 worked things out ?
Thanx
I don’t have access to IE7, but it does not support XHTML. Either there’s something trivial, like you’re seeing a cached previous version of the page that was served as text/html, or else Microsoft have tweaked IE7 to accept application/xhtml+xml even though it doesn’t support it (presumably treating it as HTML).
The sample you posted seems to be a valid XHTML 1.1 document, although the <meta/> element is pointless – especially if you serve it as application/xhtml+xml. You can’t change the content type this way, and the usual reason for including it in HTML and pretend-XHTML pages is to specify the character encoding. In real XHTML and other XML documents, the encoding should be specified by the XML declaration, just like in your sample.
But I also edited the html to add the php code at the beginning:
<?php
header('Content-type: application/xhtml+xml');
header('Cache-Control: no-store, no-cache, must-revalidate, pre-check=0, post-check=0, max-age=0');
?>
which doesn’t cache the page and it still displays correctly. I guess IE7 must have been improved to atleast read it and treat it as html. But Im glad FF is treating it as XML, it makes error-checking mush easier - instead of depending on FireBug and HTMLValidator for every small misplaced tag.
It can still be in IE7’s cache (if the previous text/html version didn’t have the Cache-Control header). Try to force a reload or load the file from disk (using .xml as file extension).
That would not be an improvement at all! Doing that is horrible. It’s like claiming to support PNG but instead interpreting image/png images as if they were GIF. Doing so is against the specs, and if authors would only test their XML documents against IE7 and it shows “fine” even though it’s not well-formed, then they would think that their documents are fine yet they would break in all other UAs.
I’m pretty sure that, unless you have hacked your registry manually, IE7 will ask you to save application/xhtml+xml resources, and text/xml or application/xml will be treated as XML (and then the XHTML namespace is not recognized).
Cleared all IE-cache and still find that IE7 displays application/xhtml+xml instead of asking to save it. It may treating it as html instead of xhtml but its definitely not asking to save.
I did not hack the registry but I did install the IE Developer Toolbar if that helps.
I tested downloading the IE Developer Toolbar but it prompts to save for me.
Did you try loading an .xml file from disk? Or try this one: http://mozillaquestquest.com/. Or try loading an application/xhtml+xml page that you know isn’t well-formed (like this one) – if your IE7 doesn’t show an XML parse error then it’s using the tag soup parser, and that isn’t the default behaviour of IE7.
FF 2.0.0.1 shows
XML Parsing Error: syntax error
Location: http://simon.html5.org/test/mobile/003.xht
Line Number 1, Column 1:This document is malformed XML. If the UA shows a parse error then this test has PASSED. If there are no parse errors then this test has FAILED.
^
IE7 shows:
Well, I guess if you didn’t hack your registry then someone else must have… 
If you have this registry key [HKEY_CLASSES_ROOT\\MIME\\Database\\Content Type\\application/xhtml+xml] then you can delete it (it doesn’t exist by default), or change it’s CLSID value to {48123BC4-99D9-11D1-A6B3-00C04FD91555} (which is the same as for application/xml).
IE7 displays this XHTML page that is sent as application/xhtml+xml and the second one that you linked to, Simon.
I thought that the DOCTYPE was required in XHTML documents?
IE7 just shows the markup for mozillaquestquest.com.
I don’t have that particular Registry key on this computer.
Yeah! It would be like interpreting text/plain documents as if they were HTML. Wait a minute … Microsoft are already doing that! 
Does IE7 render this page, which is definitely sent as application/xhtml+xml?
No, with that page I get an error in IE7. It says that it couldn’t open that Internet site. Maybe it’s because that page uses the .php extension.
Hmm… perhaps you have the MathPlayer plugin, or some other plugin, which makes IE accept application/xhtml+xml but treat it as text/html. Perhaps if you create that key it will override the plugin?
Not really. All it does is reference a DTD. All browsers that support XHTML use so-called non-validating XML parsers, that is they don’t fetch the external subset. IE7, however, does fetch the external subset so it will have to download the DTD before it can start to parse the document. The DTD is not necessary to parse the document (which is why other browsers don’t fetch it, and which is why XML has the concept of well-formedness in the first place) and thus fetching it is just a waste of bandwidth and time. It is therefore recommended nowadays to not include a doctype declaration in XML documents.
That’s what it should do. XHTML is just generic XML to IE, since the namespace is not recognized.
http://www.w3.org/2002/04/xml_bugs/#bug2
(The page would render just fine and much faster if the doctype declaration wouldn’t be present – hint hint ;))
I don’t remember installing that plug-in and it doesn’t seem to be in the list of installed IE plug-ins. Adding that key does make IE7 treat application/xhtml+xml like it handles text/xml, ie. it shows the XML source.
Hmmm… But won’t browsers render…? Do all browsers that actually support XHTML properly render pages served with an XML mime-type in Standards mode even when a doctype is not present?
I know. I was just reporting what it was doing.
You seem to have lost me.
Yes. Browsers only do doctype sniffing for text/html; XML is always standards mode.
It’s a bug in IE’s XML parser. The XHTML 1.1 DTD contains something equivalent to this:
<![IGNORE[ %foo; ]]>
…where %foo; is not defined anywhere, so IE aborts even though it should ignore the marked section.
If the page didn’t have the doctype declaration, IE wouldn’t fetch the DTD, and thus this problem wouldn’t occur.
Although if you got some other error message then I don’t know.