I've just noticed that template for XHTML/1.1 has been changed to include application/xhtml+xml content type in <meta> element.
This is completly misguided as <meta> is there only for backwards-compatibility non-XHTML user-agents -- that is only those which *do not* support application/xhtml+xml.
From W3C XHTML FAQ: "Note that a meta http-equiv statement will not be recognized by XML processors, and authors SHOULD NOT include such a statement in an XHTML document served as 'application/xml' (and 'application/xhtml+xml' as well for that matter)."
Please change it back to text/html or remove <meta> element completly.
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
That's what my recently updated XHTML/1.1 reads...
Brett
On Mar 4, 2007, at 6:00 PM, porneL wrote:
I've just noticed that template for XHTML/1.1 has been changed to include application/xhtml+xml content type in <meta> element.
This is completly misguided as <meta> is there only for backwards- compatibility non-XHTML user-agents -- that is only those which *do not* support application/xhtml+xml.
From W3C XHTML FAQ: "Note that a meta http-equiv statement will not be recognized by XML processors, and authors SHOULD NOT include such a statement in an XHTML document served as 'application/xml' (and 'application/ xhtml+xml' as well for that matter)."
Please change it back to text/html or remove <meta> element completly.
-- regards, porneL
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
On 5. Mar 2007, at 01:00, porneL wrote:
I've just noticed that template for XHTML/1.1 has been changed to include application/xhtml+xml content type in <meta> element.
This is completly misguided as <meta> is there only for backwards- compatibility non-XHTML user-agents -- that is only those which *do not* support application/xhtml+xml.
From W3C XHTML FAQ: "Note that a meta http-equiv statement will not be recognized by XML processors, and authors SHOULD NOT include such a statement in an XHTML document served as 'application/xml' (and 'application/ xhtml+xml' as well for that matter)."
The reason it says SHOULD NOT (which means “not recommended”, see RFC 2119) is that for an XML document, you declare the content type using processing instructions. Though I have no idea how the “content type” processing instruction looks, anyone?
Please change it back to text/html or remove <meta> element completly.
The type of an XHTML 1.1 document is application/xhtml+xml, so if we want to actually serve XHTML, we should not change it, and if we don’t want to serve XHTML 1.1, we probably should not use the XHTML 1.1 template ;)
We can remove it, but then we should add the proper XML processing instruction, as we can’t IMO rely on the document always being served over http. Though as said, I have no idea how this PI looks.
On 3/4/07, Allan Odgaard throw-away-1@macromates.com wrote:
On 5. Mar 2007, at 01:00, porneL wrote:
I've just noticed that template for XHTML/1.1 has been changed to include application/xhtml+xml content type in <meta> element.
This is completly misguided as <meta> is there only for backwards- compatibility non-XHTML user-agents -- that is only those which *do not* support application/xhtml+xml.
From W3C XHTML FAQ: "Note that a meta http-equiv statement will not be recognized by XML processors, and authors SHOULD NOT include such a statement in an XHTML document served as 'application/xml' (and 'application/ xhtml+xml' as well for that matter)."
The reason it says SHOULD NOT (which means "not recommended", see RFC 2119) is that for an XML document, you declare the content type using processing instructions. Though I have no idea how the "content type" processing instruction looks, anyone?
If it's an xml file, doesn't that already imply the the content-type is xml? Isn't the content only important when you're sending things "over the wire" so the program at the other end can recognise what to do? The meta tag is just a hack for html to give the page author some way of overriding the content-type that the server is sending.
There's a good discussion of xhtml here: http://www.hixie.ch/advocacy/xhtml. I think this sums it up:
"HTML 4.01 contains everything that XHTML 1.0 contains, so there is little reason to use XHTML in the real world. It appears the main reason is simply "jumping on the bandwagon" of using the latest and (perceived) greatest thing."
Hadley
On 3/5/07, hadley wickham h.wickham@gmail.com wrote:
On 3/4/07, Allan Odgaard throw-away-1@macromates.com wrote:
On 5. Mar 2007, at 01:00, porneL wrote:
I've just noticed that template for XHTML/1.1 has been changed to include application/xhtml+xml content type in <meta> element.
This is completly misguided as <meta> is there only for backwards- compatibility non-XHTML user-agents -- that is only those which *do not* support application/xhtml+xml.
From W3C XHTML FAQ: "Note that a meta http-equiv statement will not be recognized by XML processors, and authors SHOULD NOT include such a statement in an XHTML document served as 'application/xml' (and 'application/ xhtml+xml' as well for that matter)."
The reason it says SHOULD NOT (which means "not recommended", see RFC 2119) is that for an XML document, you declare the content type using processing instructions. Though I have no idea how the "content type" processing instruction looks, anyone?
If it's an xml file, doesn't that already imply the the content-type is xml? Isn't the content only important when you're sending things "over the wire" so the program at the other end can recognise what to do? The meta tag is just a hack for html to give the page author some way of overriding the content-type that the server is sending.
See also:
http://ln.hixie.ch/?start=1144794177&count=1 http://ln.hixie.ch/?start=1154950069&count=1
which support what I meant to say: browsers use complicated heuristics to determine the actual content-type of a page - and the http content-type and html meta tag are often ignored.
Hadley
On 5. Mar 2007, at 17:13, hadley wickham wrote:
[...] If it's an xml file, doesn't that already imply the the content- type is xml?
This is circular logic ;)
Also, we want to further specialize the type, i.e. it could be xhtml +xml (as in this case) or it could be rss+xml, that is what we need to specify.
Isn't the content only important when you're sending things "over the wire" so the program at the other end can recognise what to do? The meta tag is just a hack for html to give the page author some way of overriding the content-type that the server is sending.
I don’t fully follow this. But the meta tag is not a hack, it is a way to specify the content type (and encoding, etc.) when the page is NOT sent over http, i.e. when it is loaded from a non-http server (like your disk drive). The meta tag never overrides the info sent by the server, on the contrary, it is the server which overrides the meta tag.
There's a good discussion of xhtml here: http://www.hixie.ch/ advocacy/xhtml. I think this sums it up: [...]
Sure, XHTML is not useful on the net, etc. -- but what we are discussing here is how a correct XHTML 1.1 template should look, regardless of what the real-life treatment of XHTML for content sent over http is.
If we wanted to cater to the real-life situation, we should really just remove the XHTML support -- but a lot of people do want to use XHTML, and some may actually do it in an environment where it makes sense. For example some produce HTML 4 from their XHTML pages, which has the advantage that they can use the full XML tool suite with their content (when in the states prior to the final publishing step).
Sure, XHTML is not useful on the net, etc. -- but what we are discussing here is how a correct XHTML 1.1 template should look, regardless of what the real-life treatment of XHTML for content sent over http is.
If we wanted to cater to the real-life situation, we should really just remove the XHTML support -- but a lot of people do want to use XHTML, and some may actually do it in an environment where it makes sense. For example some produce HTML 4 from their XHTML pages, which has the advantage that they can use the full XML tool suite with their content (when in the states prior to the final publishing step).
If I'm developing content for mobile phones then I do want real XHTML, some phones don't like HTML and some phones render differently between text/html and XML+XHTML.
Regards
Scott
[...] If it's an xml file, doesn't that already imply the the content- type is xml?
This is circular logic ;)
I agree :) How can you have a content-type specification instruction which tells the processor what content-type this document is? ie. <meta http-equiv="Content-Type" content="application/pdf; charset=utf-8"/> doesn't make any sense.
Also, we want to further specialize the type, i.e. it could be xhtml +xml (as in this case) or it could be rss+xml, that is what we need to specify.
Does rss+xml have a <meta> tag?
Isn't the content only important when you're sending things "over the wire" so the program at the other end can recognise what to do? The meta tag is just a hack for html to give the page author some way of overriding the content-type that the server is sending.
I don't fully follow this. But the meta tag is not a hack, it is a way to specify the content type (and encoding, etc.) when the page is NOT sent over http, i.e. when it is loaded from a non-http server (like your disk drive). The meta tag never overrides the info sent by the server, on the contrary, it is the server which overrides the meta tag.
see above, and links in the other email I sent. I'm not sure that this is the full story.
There's a good discussion of xhtml here: http://www.hixie.ch/ advocacy/xhtml. I think this sums it up: [...]
Sure, XHTML is not useful on the net, etc. -- but what we are discussing here is how a correct XHTML 1.1 template should look, regardless of what the real-life treatment of XHTML for content sent over http is.
Fair enough.
Hadley
Allan Odgaard wrote:
On 5. Mar 2007, at 17:13, hadley wickham wrote:
Isn't the content only important when you're sending things "over the wire" so the program at the other end can recognise what to do? The meta tag is just a hack for html to give the page author some way of overriding the content-type that the server is sending.
I don’t fully follow this. But the meta tag is not a hack, it is a way to specify the content type (and encoding, etc.) when the page is NOT sent over http, i.e. when it is loaded from a non-http server (like your disk drive). The meta tag never overrides the info sent by the server, on the contrary, it is the server which overrides the meta tag.
Okay, here's what Ian Hickson said in response to my email:
On Mon, 5 Mar 2007, Jacob Rus wrote:
Even though xhtml has real problems for use on the web, and should probably be avoided by most users, some users need it for specific applications, and so it would be good to include a correct and useful default template for xhtml 1.1. So, is it wrong to include the `<meta>` tag, or is there some better way to indicate content type within an xml document?
If the file is XML, it shouldn't have a <meta> with Content-Type data. It will never be used by the browser (it's only used when the browser already knows it's HTML).
In fact, the "text/html" part of the Content-Type <meta> line is never examined. That line is only ever examined for working out the encoding of HTML documents. For XML documents that are actually treated as XML, the
<?xml?> declaration is the one that matters.
HTH,
And on a bit more prodding:
So should a generic XHTML 1.1 template have a <?xml?> declaration then?
If you want to declare the encoding, yes.
So I think we should make the default template instead look like:
<?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" version="-//W3C//DTD XHTML 1.1//EN" xml:lang="en"> <head> <title>${TM_NEW_FILE_BASENAME}</title>
</head>
<body>
</body> </html>
-Jacob
Jacob Rus wrote:
So I think we should make the default template instead look like:
<?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" version="-//W3C//DTD XHTML 1.1//EN" xml:lang="en"> <head> <title>${TM_NEW_FILE_BASENAME}</title> </head> <body> </body> </html>
And actually, I'm not so sure we really need the `version` attribute of the `html` tag, either. I can't find any xhtml 1.1 documents on the web that use such an attribute.
-Jacob
On Mon, 05 Mar 2007 01:11:22 -0000, Allan Odgaard throw-away-1@macromates.com wrote:
This is completly misguided as <meta> is there only for backwards- compatibility non-XHTML user-agents -- that is only those which *do not* support application/xhtml+xml.
From W3C XHTML FAQ: "Note that a meta http-equiv statement will not be recognized by XML processors, and authors SHOULD NOT include such a statement in an XHTML document served as 'application/xml' (and 'application/xhtml+xml' as well for that matter)."
The reason it says SHOULD NOT (which means “not recommended”, see RFC 2119) is that for an XML document, you declare the content type using processing instructions. Though I have no idea how the “content type” processing instruction looks, anyone?
If document is sent with application/* content-type, you can declare character set of XML document using XML declaration (which is often mistaken for processing instruction), but there's no way of declaring content-type (MIME type) that I'm aware of.
Please change it back to text/html or remove <meta> element completly.
The type of an XHTML 1.1 document is application/xhtml+xml, so if we want to actually serve XHTML, we should not change it
There are only two cases: 1. If XHTML is served as XML (using any of the recommended XML media types), the <meta> is completly ignored, so it doesn't matter whether there is application/xhtml+xml, text/html or video/mpeg - it's ignored, irrelevant and cannot affect document in any way. 2. if XHTML is served as text/html, the <meta> with application/xhtml+xml states contradictory information. <meta> cannot change processing mode and even if it could - it would lead to case #1.
we can’t IMO rely on the document always being served over http.
XHTML relies on externally specified media type already. Browsers even parse local XHTML files differently basing on content-type supplied by the OS (or file extension).
Just a thought, but isn't the <meta> tag generally about Metadata, and I think from what most people are saying it's disregarded by most, if not all browsers. So isn't it's purpose then to just add metadata to the document and not provide ANY processing instructions to the parser (be it a browser or not), and thus shouldn't it then stay as "application/xhtml+xml" so it is accurate metadata?
Just my thoughts on the issue at hand.
-Brian