Monday, August 29, 2005
XHTML Considered Harmful
This has to end, primarily because XHTML is a useless technology that is retarding progress, especially when it comes to Dymamic HTML (DHTML) and AJAX applications.
Here are my top eight reasons on why XHTML is Considered Harmful:
Would it be nice to not have to need document.write? Of course. Does the real state of the web require it? Currently it does.
XHTML drops iframes, which are again important in the AJAX toolkit.
Technically, iframes are supported in XHTML Transitional but not XHTML Strict. However, future-proofed support for iframes in XHTML do not exist beyond the DHTML Transitional DTD. There is also something called XFrame that supposedly creates iframe like functionality for XHTML, but XFrame is vaporware.
3. Custom attributes are sinfulIn DHTML programming, using custom attributes that aren't in HTML can be a very effective way to create readable and reusable code. For example, imagine if we model a Wiki page with the following markup:
lastEdited="Monday 3rd, 2005"
tags="technical ajax important">
<h1 class="title">My Wiki Page</h1>
<span class="author" role="manager">
<span class="content" editableBy="managers">
This is some content
Yes, I know I can technically model this using the microformat HTML data definition list, but using custom attributes is a much quicker and much more readable way of achieving the same thing.
var wikiPage = document.getElementById("wiki-page");
var lastEdited = wikiPage.getAttribute("lastEdited");
var lastEditedBy = wikiPage.getAttribute("lastEditedBy");
XHTML frowns on these, since they don't validate. The XHTML cult has a very complicated way to achieve validation while having custom attributes, but why is it worth doing so much work when XHTML is not needed?
generally slower. For example, the XHTML renderer in Safari and Mozilla do not support incremental rendering of the page as it is loading, creating slower perceived performance for end users.
5. Internet Explorer does not support XHTMLThe major browser does not support XHTML, requiring one to do some funky stuff in their XHTML to get it to display in IE. For example, you have to put a space after an empty BR tag or else IE breaks on it:
application/xhtml+xmlMIME type, which specifies that we are using a specific XML dialect. Unfortunately, because of IE's non-support of XHTML you have to "lie" to it and other browsers and specify the MIME type as
text/html, which technically means that the browser should not treat this as an XML application. This is yet another example of how adopting the XHTML ideology creates problems down the road.
7. The W3C's MITization of the web is not a good thingThere is a rumour on the web that the W3C has finally, after centuries of discussion, discovered how many angels can fit on the head of a pin.
Tim Berner's Lee creation of the original web was genius; it was a good enough, worse is better solution to a pressing problem. Cascading Style Sheets, the Document Object Model, and more were also well done, with a wee bit of cruftiness. XML was an excellent addition to the pantheon of web standards.
In the mean time, notice what hasn't come from the W3C: RSS; real world web services with REST rather than XML-RPC and the SOAP superstructure; XmlHttpRequest, created by the pragmatists at Microsoft; and more.
8. XHTML provides no benefitsAt the end of the day, the real indictment of XHTML is that it simply provides no real advantages. Yes, in a perfect world, it would be great to have HTML as a full XML application, with support for arbitrarily nested namespaces so that you could do cool stuff like embed SVG and MathML right into your app. However, nested namespaces in XHTML are simply not well supported, and may never be in time for XHTML to work out.
What exactly does XHTML do for you, other than to give you "future-proofness"? I predict that using XHTML in a deep way will actually not future proof your application; instead, as XHTML joins the list of other failed W3C standards, such as RDF, XML Schema, etc., XHTML in your application will become a legacy burden that future programmers will complain about around the water cooler, how the last guy who left several years ago drank the XHTML cool-aid and then left them with the task of working around its burdens.
SummaryWell designed, semantic HTML is enough. Perhaps when the WHAT working group comes out with their superior embraced and extended HTML and XHTML standards, XHTML will finally be useful. Currently, the cult of XHTML provides no benefits and is in fact retarding progress. It's time for those on the other side to take a stand.
I absolutely disagree that document.write is needed for DHTML. I have experience in writing DHTML and W3C DOM run from script at the end of <body> works very well for me. Transformations of existing DOM tree allow much better backwards compatibility.
Custom HTML attributes aren't sinful in XHTML any more than in HTML, but in XHTML you don't have to create custom *HTML* attributes. You can use your own namespace keep XHTML valid (DTD-based W3C validator sucks, ignore it).
IE is harmful to XHTML. That's it.
Mime Type is nothing special. There is HTTP content negotiation for that.
MITization of anti-XHTML arguments. W3C issues are not part of this technology.
XHTML provides very little benefits, I agree. Still far from being harmful.
#2: IFRAME is supported in XHTML (just like you mentioned). XHTML did not drop IFRAME, HTML4 did! IFRAME is illegal in HTML4 Strict. XHTML is an exact reformulation of HTML4 in XML, it does not drop anything and it does not add anything.
If you want to use the Strict flavor, use OBJECT instead of IFRAME.
#3: Non-standard attributes are equally invalid HTML as XHTML. If you want custom attributes to validate as HTML, you still need to create your custom DTD as in XHTML, although that is in fact forbitten by the spec.
#4: They don't support incremental renering, but otherwise I don't see why they are slower or more buggy.
#5: IE doesn't break if you don't have a space before the slash. Netscape 4 does (given it's sent as text/html).
#6: HTML also has to be sent with its correct MIME type, text/html. If you want to support IE, then obviously XHTML is not an option because IE doesn't recognise the namespace. Don't let the MIME type distract you, application/xml has been supported for years.
#7: How is this related to XHTML?
#8: XHTML has the benefit of being XML. If that doesn't bring any benefits to you, then you don't need to use it.
I don't really see how your points make XHTML harmful. Alpha transparency in PNG is also not supported by IE. Is PNG harmful?
Plus, web clients are written to play nicely non-compliant HTML/XHTML. Can you imagine web browsers dealing with XHTML the way XML parsers do? hehehe....
at og.apache.xerces.dom.ParentNode.nodeListItem(Unknown Source)
at org.apache.xerces.dom.ParentNode.item(Unknown Source)
XHTML seems to be a means to an end - getting HTML ready for XML parsers, in order to extract data from a document. Not the same purpose as any jane or joe wanting to put a web page up without having to learn how to dot every 'i' in the specification.
For the rest of us, there's street HTML, and that ain't going away any time soon.
Besides.. If I need to connect systems and the only way is through http I put a web service or set a dynamic page that serves pure XML. Easy.
La la la land on one for all is too much work.
However, XHTML does have one major advantage which you don't mention. Because it is XML, you can perform transformations on it which would be cumbersome or impossible on HTML. Hence you could take XHTML and convert it to LaTeX by extending the Jade tools if you want.
This being said, the general rule I expound is: Without the need for transformation, XML is the wrong tool for the job!
Links to this post:
Subscribe to Posts [Atom]