Coding In Paradise

One of the current religions floating around the web is XHTML Compliance. If you post a technique or article that is not XHTML compliant, a horde of XHTMLites will descend on you. Many a blogger has trembled in fear before pressing the submit button on a post that might offend XHTML sensibilities. Evil are those who do not XHTML validate before the W3C!

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:

1. document.write is not supported

document.write is an extremely important tool in the professional DHTML programmers tool chest. If you create AJAX frameworks that require the page to have certain elements to work, for example, such as hidden iframes and so on, doing a document.write on page load can make it much easier for third-party developers to use your framework without having to know the specific elements you need to get things working.

Further, dccument.write is sometimes needed for obscure, but important, hacks to get things like DHTML history going.

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.

2. iframes are not supported

The W3C purists don't believe in web based applications or compound documents. This means they don't think about important things like iframes when it comes to building web applications, not just simple web pages.

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 sinful

In 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:

<div id="wiki-page"
      lastEdited="Monday 3rd, 2005"
      lastEditedBy="Brad Neuberg"
      tags="technical ajax important">
<h1 class="title">My Wiki Page</h1>
<span class="author" role="manager">
             Brad Neuberg
      </span>
<span class="content" editableBy="managers">
 This is some content
</span>
</div>

Later, I can grab on to these custom attributes in my JavaScript code just like any other attributes:

var wikiPage = document.getElementById("wiki-page");
var lastEdited = wikiPage.getAttribute("lastEdited");
var lastEditedBy = wikiPage.getAttribute("lastEditedBy");

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.

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?

4. The XHTML layout engines are slower and buggier

The XHTML layout engines in some browsers is much newer, which means they have more bugs and are 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 XHTML

The 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:

<br />

6. XHTML has to be sent using incorrect MIME types

The correct way of sending XHTML over is using the application/xhtml+xml MIME 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 thing

There 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 last few years, however, what has the W3C given us? RDF is a terrible solution to an extremely important problem, namely metadata. RDF is almost as much fun as DSSSL and HyTime (What are those? Exactly), and has crowded better solutions to the metadata problem out of the standards marketplace. XML Schema is equally terrible, a brittle and complicated solution to an important problem, namely clear data types when describing XML languages. The W3C has become as good as the Java Community Process at creating high-quality specs, which is not a compliment.

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 benefits

At 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.

Summary

Well 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.

The new release of Rojo makes it possible to include right into your blog cool Rojo features (disclosure: I used to work for Rojo). Rojo calls them 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
  

When I was at Rojo we implemented our behind the scenes server communication using a hidden iframe rather than XmlHttpRequest, partially because we created this system before Google legitimized using XmlHttpRequest in production systems (as a side note, when I first came to Rojo I was advocating that we use more DHTML, before it was called AJAX, and they look at me like I was a wild eyed lunatic -- its amazing how far DHTML has come from being the ignored, discredited kid on the block to the next big thing).

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]

Nicholas C. Zaka sent me a comment recently where he responded to my post on using Internet Explorer's proprietary Vector Markup Language (VML) to create an implementation of Safari's canvas:

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.

Alex Lynch keeps knocking the ball out of the field. A few days ago he posted a version 2.0 release of P2P Sockets, along with another small minor release to fix a bug some folks had found. Check out the P2P Sockets web page to find out more on this release and grab it for yourself! I also know that Alex is working on some cool (secret) new features that will make P2P Sockets much more applicable for all apps; you'll just have to wait until he finishes them to check them out.

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.