Forum Moderators: open
To go back to the SHORTTAG minimization in HTML 4 ... Saying that "it's ok to send XHTML as HTML 4.01" simply because no browsers have implemented shorttag minimization is dangerous. You are now relying on a browser bug to get your documents to render correctly. I, for one, hope that the Gecko engine will fix this problem and implement shorttag minimization properly, in order to be more fully HTML 4 compliant.
Finally, on to a very important point... We all know by now that XHTML served as text/html is truly "HTML 4.01 in quirksmode". Unfortunately, when using the W3 validator to validate a document (with XHTML doctype specified) it should truly force a doctype override. Thus, if you have specified XHTML Strict, the validator should validate against HTML 4.01 Strict when the document is sent as text/html as this is what browsers will treat it as anyway. Further, as XHTML documents sent as text/html are not really XHTML to begin with, all the XHTML requirements (such as wellformedness, closing all tags [including empty ones like "<br />"]) are no longer in effect, wherefore you can safely write plain ol' HTML 4.01 compliant markup, throw in the XHTML doctype ... as long as you serve the document as text/html. If that doesn't sound messed up, I don't know what does.
Web Quirksmode 2.0
The XHTML family is the next step in the evolution of the Internet. By migrating to XHTML today, content developers can enter the XML world with all of its attendant benefits, while still remaining confident in their content's backward and future compatibility.
[w3.org...]
Does that mean that the suggestions from the W3 are to be questioned?
WITH the two, however ... yes, the there are certainly benefits to be had!
XHTML family document types are XML based
So I would like to understand better what’s happening
I used to praise up XHTML, but I believe that until it is fully supported (i.e. we have the ability to send it with the correct mime type and prolog), we should use HTML 4.01 strict instead.
Obviously if you are developing a site for an intranet, where you know everyone in your company is using firefox, then feel free to use XHTML with the correct prolog and mime type, but if you're developing a public site then I see no point in using it just yet.
Unfortunately, I believe that everyone just ran to XHTML without thinking about the consequences. It was the latest thing, all the standards gurus were going on about it, but nobody really took the time out to see how this new markup language worked, and what affect it had on other technologies.
That pretty much describes me. After reading "Sending XHTML as text/html Considered Harmful ", I plan to change my documents from being XHTML 1.0 served as text/html to being HTML 4.01 Strict.
Thanks to DrDoc for posting the link.
XHTML served as text/html is truly "HTML 4.01 in quirksmode"
Well, to be fair, a document with an XHTML doctype is parsed in standards-compliance mode rather than quirks mode (except in IE6 when preceeded by an XML prolog), but it is true to say it is parsed as "HTML with errors" (the undefined attributes which constitute the trailing slashes).
The validator won't complain about XHTML served as
text/htmltext/htmlDrDoc:
Saying that "it's ok to send XHTML as HTML 4.01" simply because no browsers have implemented shorttag minimization is dangerous. You are now relying on a browser bug to get your documents to render correctly. I, for one, hope that the Gecko engine will fix this problem and implement shorttag minimization properly, in order to be more fully HTML 4 compliant.
They will never do it, simply because it will break legacy XHTML 1.0/
text/htmlRobert Lofthouse:
Unfortunately, I believe that everyone just ran to XHTML without thinking about the consequences. It was the latest thing, all the standards gurus were going on about it, but nobody really took the time out to see how this new markup language worked, and what affect it had on other technologies.
Firstly, welcome to WebmasterWorld Robert, and thank you for your input! I think there has been a shift in the message carried by what we can generally call "standards evangelists" over the last couple of years for serveral reasons. When the XHTML specifications were published, they were seen as a great leap forward from the prevalent "tag soup" HTML. There was an assumption that the tools and browser support would rapidly follow, and that XHTML would push HTML into obsolescence.
I count myself in this group, and I was already producing XHTML documents served as
application/xhtml+xmlThe second failure of XHTML was with the implementation - the specification itself is flawed-to-broken. In almost every case of even very experienced developers putting in place a "true" XHTML solution for a public (not test) website, the difficulties and disadvantages of using
application/xhtml+xmlThe message from standards evangelists is much more mitigated than in the early days. There was a great deal of "HTML is eeeeviiiil" and "tables are eeeeviiiil", and a certain utopian feel to the refrains. But I think it is now a mistake to suddenly switch to a "XHTML is eeeeviiiil" discourse which is equally uncompromising. The idea is not (as in the early days) to assume that HTML is going to disappear rapidly from the scene and be replaced by XML variants. Rather it is more important to to consider "now-compatibility" rather than "forwards-compatibility". We messed up predicting the future so let's talk about what you should be doing here and now to produce robust, well-built, compatible websites.
If you are building a site today, HTML 4.01 Strict is the best choice, as it has the best user agent support, has the advantage of legacy support too, is easiest to parse and render by the widest variety of browsers and search-engine spiders today.
XHTML 1.0 served as
text/htmlIs XHTML ideal? No, but then using tables for layout isn't either, but surely we should pull back from standards extremism and suggest a more pragmatic approach to standards compliance?
A useful reference guide to XHTML from the W3C is: HTML and XHTML Frequently Answered Questions [w3.org].
First, let me preface my statement by saying that I am not completely anti-XHTML. As someone cleverly pointed out to me in a sticky, I use XHTML myself (I was wondering how long it would take for anyone to point that out). ;)
What I am against, however, is uneducated and misinformed implementations of XHTML without fully understanding the implications. Way too often have I seen XHTML implementations which were so carelessly carried out as to completely missing the target. XHTML can, and perhaps should be, a viable alternative for public consumption if, and only if, it is implemented 100% correctly.
What this means is that you should not use XHTML unless:
The education can best be carried out in two ways: first, careful reading and pondering of Ian Hickson's article; second, careful reading and pondering of W3C's XHTML documentation. Read until you understand.
Once you have gained the needful knowledge about XHTML through the two aforementioned documents you can move to implement your newfound knowledge. Doing so requires more than mere markup. Reading between the lines in both Ian's article and W3C's documentation, one more change is necessary. You should ensure that your server does the following, whether directly in your server's settings, or through explicit header output through server side scripting.
To avoid throwing IE into quirksmode we really want to avoid including the XML prolog on our pages. In order to do so, the W3C documentation declares that character set must be specified by a "higher protocol". To you, that means it must be sent by the server. Again, this can be done directly in the server configuration, or by properly outputting the appropriate "content-type" header.
Now, in all honesty it should be said that sending XHTML as text/html is not going to cause severe problems in IE. But, doing so across the board is also not going to justify using XHTML over HTML 4.01, as "text/html" effectively nullifies use of XHTML to begin with, and removes any of the benefits for choosing XHTML in the first place. You therefore want to check whether the browser sends the
HTTP_ACCEPTIf
HTTP_ACCEPTapplication/xhtml+xmlContent-Type: application/xhtml+xml;charset=ISO-8859-1HTTP_ACCEPTapplication/xhtml+xmlContent-Type: text/html;charset=ISO-8859-1HTTP_ACCEPTContent-Type: application/xhtml+xml;charset=ISO-8859-1In PHP, that is accomplished 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");
}
else {
header("Content-Type: text/html;charset=ISO-8859-1");
}
header("Content-Style-Type: text/css");
header("Content-Script-Type: text/javascript");
?>
Adjust charset as appropriate. I put the content-style-type and content-script-type headers in there for good measure as well.
Now, by doing that you are not only sending XHTML according to the W3C recommendations, you are truly making your site both forward and backward compatible while doing what XHTML was designed to do -- taking the web one step closer to being able to fully utilize the power of XML.
If you are incapable of the above implementation, or simply lack the ability to do so, stick with HTML 4.01 as it is the better tool for the job at this point.
HTTP_ACCEPTtext/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5Your code will serve the document as
application/xhtml+xmlHTTP_ACCEPTtext/html,application/xhtml+xml;q=0.9,application/xhtml+xml;q=0.8,text/plain;q=0.7,image/png,*/*;q=0.5Then your code will still serve
application/xhtml+xmltext/htmlI also use XHTML for one large (30K+ pages) site. I serve it as
text/htmlShould I try to serve this content as
application/xhtml+xmlapplication/xhtml+xmltext/htmlapplication/xhtml+xmlThe "MIME-type switching" idea is flawed too, because it actively penalizes conformant browsers when an error inevitably occurs. the document becomes fragile in
application/xhtml+xmlapplication/xhtml+xmltext/htmlFinally, using XHTML and
application/xhtml+xmlapplication/xhtml+xmlFor reference, a semi-related article (which discusses mostly syndication formats, but the same issues exist for XHTML): XML on the Web Has Failed [xml.com].
