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.
Rojo Now Features Scriptlets
"So you want to add some Rojo features to your blog or web site? Well, you have come to the right place. Here you will learn how to add some simple scripts to your blog template or web page page that will make some of your Rojo experience available to readers on your site! Here some simple examples, followed by an explanation of the styling structure and some parameters that you can add to control the results."
See more on the Rojo Wiki.
You can currently at the following to your website or blog, dynamically including Rojo functionality:
- Your recent stories
- Stories you have flagged
- Stories you have shared
- Stories by tag
Someone Hacked Rojo Using Greasemonkey!
A talented blogger recently created several cool Greasemonkey scripts that modify how Rojo works behind the scenes, swapping out our old iframe approach for an XmlHttpRequest one! It's amazing that an independent programmer, outside of the company, can totally revamp how Rojo works, making it faster and easier to work with. That's really cool.
[Updated broken link]
AJAX: More On Implementing Safari Canvas on Internet Explorer
Interesting, I had the same thoughts a while back. I definitely think it should be possible to emulate in IE using behaviors and VML.
He also pointed me to an interesting discussion where he and such DHTML super stars as Erik Arvidsson discuss the options available in Internet Explorer for creating a canvas widget implementation.
New 2.0 Release of P2P Sockets!
More about P2P Sockets:
P2P Sockets makes it easy to write peer-to-peer applications based on JXTA. P2P Sockets allows programmers to gain much of the power of JXTA, such as NAT and firewall traversal, without being exposed to its complexity. It does this through ports of popular software projects, such as a web server and web services stack, to work on the JXTA peer-to-peer network. This includes a web server (Jetty) that can receive requests and serve content over the peer-to-peer network; a servlet and JSP engine (Jetty and Jasper) that allows existing servlets and JSPs to serve P2P clients; an XML-RPC client and server (Apache XML-RPC) for accessing and exposing P2P XML-RPC endpoints; an HTTP/1.1 client (Apache Commons HTTP-Client) that can access P2P web servers; a gateway (Smart Cache) to make it possible for existing browsers to access P2P web sites; and a WikiWiki (JSPWiki) that can be used to host WikiWikis on your local machine that other peers can access and edit through the P2P network. P2P Sockets also introduces implementations of java.net.Socket and java.net.ServerSocket that can work on the JXTA network as well as a simple, light-weight, distributed, human-friendly, and non-secure DNS system.
Subscribe to Posts [Atom]