Forum Moderators: open
Although IE cannot handle
application/xhtml+xml there is a trick which allows you to send XHTML as [b]application/xml[/b]! Although the preferred mime type for XHTML is application/xhtml+xml, you can send XHTML to IE in a way which forces it to parse the document as XML (which is what we want) while at the same time displaying it as regular HTML (which is exactly what XHTML is supposed to do)! So, the PHP header thingy now looks as follows:
<?php
if((
isset($_SERVER["HTTP_ACCEPT"])
AND stristr($_SERVER["HTTP_ACCEPT"], "application/xhtml+xml")
) ¦¦ (
!isset($_SERVER["HTTP_ACCEPT"])
)) {
header("Content-Type: application/xhtml+xml;charset=ISO-8859-1");
}
elseif(isset($_SERVER["HTTP_ACCEPT"]) AND stristr($_SERVER["HTTP_USER_AGENT"], "MSIE 6.0")) {
header("Content-Type: application/xml;charset=ISO-8859-1");
}
else {
header("Content-Type: text/html;charset=ISO-8859-1");
}
header("Content-Style-Type: text/css");
header("Content-Script-Type: text/javascript");
header("Content-Language: $lang");
echo "<?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>
<?xml-stylesheet type=\"text/xsl\" href=\"/copy.xsl\"?>
";
?>
My
copy.xsl file contains:<stylesheet version="1.0" xmlns="http://www.w3.org/1999/XSL/Transform">
<template match="/">
<copy-of select="."/>
</template>
</stylesheet>
And it works! I tried sending a non-wellformed XHTML document to IE, and it complains like it should!
Yes, XHTML might break. Thus, you are not capable of using it in your environment. If you use tools which are incapable of producing correct markup, or are unable to fix the output yourself, then there is no need for you to use XHTML at all. You might as well throw the HTML 4.01 doctype in there, as your pages wouldn't validate anyway, and there wouldn't be any drawbacks.
I also use XHTML for one large (30K+ pages) site
You are, however, right that the HTTP_ACCEPT check is flawed in that it does not consider weighting. Then again, it is no more flawed than explicitly sending something as text/html. The page is only available in one format. It just differs depending on whether you can handle it or not.
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US" lang="en-US">
<head profile="http://www.w3.org/2000/08/w3c-synd/#">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hmmm... The W3C uses XHTML Strict with content="text/html".
Sounds fishy.
You can use XHTML 1.0 Strict with text/html.
The text/html and application/xhtml+xml mimes will render exactly the same if you code correctly in both Gecko and Presto based browsers.
My site uses XHTML 1.1 with application/xhtml+xml. When you change the DTD or Mime (accessible via the personal toolbar) the rendering does not change. I've worked very hard to ensure it meets all the standards but keep in mind we all have different methods of coding.
So in that case has anyone noticed differences in rendering when changing their site (but not CSS) between HTML 4 and XHTML. I ask this question with one string attached, removing the trailing slashes when testing with HTML 4 that are required by XHTML.
While I have yet to do this specifically myself sites served as XHTML 1.1 with application/xhtml+xml should detect bots and serve the XHTML 1.0 Strict DocType as text/html. I am not aware of what bots support application/xhtml+xml and which do not but I currently do not run that chance. I simply serve bots XHTML 1.1 as text/html (until I have a chance to further address this in the future). The main point is that they are still able to read the pages and no harm (to my current understanding) is being done.
It's more of a bragging right to get on the edge but support legacy programs (such as IE6/7) and bots that do not recognize application/xhtml+xml.
I look at it this way, if they update a law in 2000 that says application/xhtml+xml is the legal HTML limit then that is what we should currently be doing. So in essence everyone using HTML 4 is breaking the law. But of course that is just an analogy and there are no such laws, just standards. Still I take standards seriously (sometimes more then that law ha-HA!)
There are downsides to XHTML. For example I am not a (good or well versed) web programmer. That means my forums and mail (are built by others until I know how to build my own and...) are currently XHTML 1.1 but served as text/html which is a no no of course. So it's important to keep working on it. If you are in the same position I simply suggest using XHTML 1.0 Strict as you are still allowed to use text/html and once you have updated your templates to change your DocType to XHTML 1.1.
DrDoc - Good point on IE's ability to handle application/xml. I'll have to look in to that myself. While I know everything I forgot most of it. ;) (JK of course)
John
PS - What is the difference between application/xml and application/xhtml+xml?
[xml.com...]
What is the difference between application/xml and application/xhtml+xml?
application/xhtml+xml [w3.org]
application/xml [w3.org]
Source code from w3.org:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US" lang="en-US">
<head profile="http://www.w3.org/2000/08/w3c-synd/#">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />Hmmm... The W3C uses XHTML Strict with content="text/html".
Sounds fishy.
Fishy, yes, buggy yes.
Since this thread started, I have been checking a little deeper into the issue, especially vs IE6.
And I found a very interesting thing.
This line "<?xml version="1.0" encoding="utf-8"?>" causes IE6 to go into "weird quirks" mode with CSS, especially lists.
What was happening was that I had a small nav list that totally refused to go flush left no matter what I did - worked fine in other browsers. It had a left margin of around 10% - and I spent about 3 hours trying to find some odd inheritance or unclosed tag someplace. Then just by chance I tried a different DOCTYPE, and left that line out.
Lo and behold - that fixed the problem with that table lining up like it was supposed to.
So even though I came in here as a non-believer, I have seen the light, and have now changed all our pages over to the standard 4.01 strict DOCTYPE.
I also found out that using UTF-8 can cause some odd behaviour - so far have seen nothing serious, but I might end up replacing that also with the standard ISO.
<bows down to Doc's infinite wisdom>
I mean the leap to XHTML will happen at some time and there are no issues in regards to rendering so does it really matter?
All the pages coded in XHTML look great in all browsers - no problem here!
So in that case has anyone noticed differences in rendering when changing their site (but not CSS) between HTML 4 and XHTML.
XHTML is hardly going to be a dead technology, as the W3C supports it, unlike what they do with HTML. And Chris Wilson, "the group program manager for the web platform and security in Internet Explorer", has publicly stated that he is a big supporter and/or fan of XHTML (I don't remember the exact wording, search for it on the IEBlog if you must know), and the IE-team have implied that its support is planned for a future version of IE.
Hmmm... The W3C uses XHTML Strict with content="text/html".Sounds fishy.
Update: Just searching for a similar topic, I stumbled upon [times.usefulinc.com...] where Edd Dumbill also outlines that it's not a fact that sending XHTML as text/html is considered harmful (and critizises the objectivity of the Google Web Authoring statistics, incidentally one day before I did [blog.skalske.dk], but that's probably another discussion...). And btw., the two IBM developerWorks articles he's linking to is surely worth reading, if you haven't already!
[edited by: Allan_Rasmussen at 10:04 am (utc) on April 3, 2006]