innerHTML

I was pleased to see that whitehouse.gov passes W3C XHTML validation and uses jQuery.

John Resig announced today that “jQuery will be distributed with Visual Studio.” Scott Guthrie, a Corporate Vice President in the Microsoft Developer Division, talks more about “adopting jQuery” in his blog.

I hope Microsoft doesn’t begin to hover over jQuery like this:

The September 2007 unveiling of jQuery UI was going to be a leap forward, in the words of John Resig: “jQuery UI signals the start of a whole new branch of the jQuery project which will focus on developing high-quality, reusable, components that you’ll be able to drop in your applications.”

On component I was happy to hear about was sortables (the demo is here). But since the new UI library’s debut, sortables, at least for me, hasn’t worked right. What do I mean by “right”? I’d argue, maybe wrongly, that if you’re building something to act like other somethings already on the web, your new something should follow the user expectations the previous somethings have already created. This is a conservative stance, but much interface design philosophy instructs us not to break patterns web users have come to expect. I’d compare it to an automaker deciding to put the gas pedal to the right of the brake. Maybe a nice new idea, but it breaks what users expect. In web design there are a few similar don’ts: don’t mess with people’s scroll bars, link to home from the upper left, keep search boxes in the upper-right corner, the list goes on. Steve Krug and Jakob Nielson have written extensively on patterns users expect.

The sortables component of jQuery UI breaks an expected pattern, at least to me. Sortables, like what you find on like iGoogle and Netvibes are a relatively new phenomena, but users have likely come to expect them to act in similar ways. Netvibes and iGoogle work almost identically: move a tile (the sortable element you’re sorting) and the tiles around the moving tile snap out of the way, making room for what you’re moving. Also, what you’re moving never hides what’s underneath and the other tiles never disappear while you’re moving one tile.

Comparing these sites to the jQuery UI demo I linked you’ll see some differences, at least two: 1) You can move one element over the top of another without the bottom element(s) snapping out of the way and 2) you can end up, in some cases, with multiple “placeholders” or empty spots where you can drop the thing you’re sorting.

Problem 1.
I made a screencast of the movie as an example. In the movie, I create a few new tiles and then move one tile over another without them moving out of the way to make room for the tile I’m sorting. Neither iGoogle or Netvibes work this way. Tiles move out of the way on both sites to make way for the tile you’re moving. But not in the jQuery UI version.

I wrote about this behavior in the Google group and filed this as a bug with the jQuery UI developers and the bug was closed with “wontfix.” A developer closed the bug with these commetns: “This is not a bug, but a thoughful implementation. However, we’ve added other tolerance modes for it – For example, tolerance: ‘pointer’.” Excellent, I thought. A fix. As usual, I thought I’d done something wrong, but looking in the sortables documentation, I found no option for tolerance. I followed up, asked for more help, but didn’t get anywhere. It’s not the developers’ faults they’re busy developing. But I’m still unable to get the jQuery UI sortable component to work like either iGoogle or Netvibes.

Problem 2.
Proliferating placeholders. In a web application I’m building, if I use the jQuery UI sortables method, I can end up with three placeholders as I’m sorting one tile. Another screencast shows what I mean.

With the above two problems, I’m unable to use the jQuery UI library for sortables. It could be that I have problems in the way I’ve coded my XHTML, that a missing end element is causing all the madness. But I’ve checked it all as best I can and built test pages and confirmed the same problems in jQuery UI’s demo. So, instead, I’m using Interface for jQuery. This sort demo is exactly the user experience a user would expect and it’s the one I’ll use until jQuery UI’s implementation becomes more flexible.

John Resig, JavaScript Evangelist for Mozilla and the creator and lead developer of jQuery, announced today that he’ll be “driving the direction of the brand-new Mozilla Firebug team” (read more).

Where would we be without Firebug? Resig himself notes that there are “trends in web development that Firebug has single-handedly revolutionized.” And that might even be an understatement.

There’s a mini-war over what MIME type to serve XHTML as: either application/xhtml+xml or text/html.

First, a definition: MIME stands for Multipurpose Internet Mail Extensions. Even thought HTTP is not email, “HTTP requires that data be transmitted in the context of e-mail-like messages, even though the data may not actually be e-mail” (see the W3C protocol). MIME types are usually defined in the server’s .htaccess file. In a (fragile) nutshell, serving a file as either application/xhtml+xml or text/html tells the browser what to do with it: treat the file as XML (a standard with strict coding guidelines) or HTML (a standard with looser guidelines).

What this means is that an invalid, i.e. not strictly coded according to XML guidelines for well-formed documents, XHTML document gets chewed up and spit out by the browser as, well, broken. As James Edwards puts it: “the strictness of a validating XML parser may be too extreme for real-world use. For an invalid XML document, browsers did not even make an attempt to parse the document as best they could, as they would with HTML—instead, they just displayed a validation error and stopped.”

There’s a significant group of developers and other groups who argue that XHTML should only be served as application/xhtml+xml. The list: Ian Hickson, Anne van Kesteren, Mark Pilgrim and the WebKit team. The W3C makes it clear as well: XHTML documents should be served as application/xhtml+xml.

I’m working on a large web application that, from the beginning in 2007, has been using XHTML 1.0 Strict DTD served as text/html. Given the above links and recommendations, this is wrong. But, as Hamlet said, “there is nothing either good or bad but thinking makes it so.”

Other developers have taken the stance that serving XHTML as text/html is fine. Brad Fults, for example, finds Hickson’s argument, “wholly unconvincing” and details why. For example, “the biggest advantages to XHTML are its readability, uniformity, well-formedness as it pertains to authoring, and the consistency of the rendered DOM (which is also a result of any well-formed HTML document).” XHTML Validation, then, is the author’s responsibility, but not a burden on the browser, which (when serving as text/html will render the page as HTML. Fults again:

Is there a harmful issue here? No. Whether or not documents validate is a completely separate issue from the MIME type as which they are sent. It is up to authors alone to worry about validating their documents with a validator.

Back to James Edwards, he takes a stance that it matters, sort of. Serving as text/html ensures that users get a readable webpage even when code might be malformed or not supported by the browser. To lean on his phrasing, an XHTML page served this way can fail cleanly.

I’ve written all this up to determine what a project I’m working on should do in terms of DTD and MIME type. Right now, I’m working on Puma, a network device visualization web application that acts as a detailed catalog of nearly 15,000 devices (routers, switches, APs, etc.). Serving the application as application/xhtml+xml, in no uncertain terms, breaks it. Somewhere in the thousands of lines of code, there’s malformed XHTML. Maybe. As a device page starts to build, a small portion of it succeeds, but at a certain point early in the process, it borks. I’m curious if it’s a JavaScript problem. A lot, maybe 95% or likely more, of the page is built by jQuery and JavaScript that relies on a JSON document for content. It seems as if when the JSON document comes into play, the borking begins. But I could be wrong.

To sum up, I’m going to continue serving Puma as text/html until the borking can be pinpointed. This way Puma can fail cleanly and still take advantage of the well-formed document structure XHTML demands.

Looking around last week for an open-source JavaScript-based calendar to use in a project, I was unimpressed, at least at first, with what was out there. And by calendar I mean “datepicker,” something that allows the user to choose a date and/or a range of dates. It seems the most full-featured around is still The (Coolest) DHTML / JavaScript Calendar. But I say “seems.” The “coolest” calendar is nearly 3 years old and there’s got to be cooler out there by now. So, for my own good, I thought I’d research the various JavaScript calendars available in the hopes that some I don’t know about might show up in the comments.

• jQuery Datepicker and a nifty version of it by the Filament Group. And a version with time.
• Clean Calendar. A favorite for its simplicity in look and in code.
• ExtJS-DatePickerPlus
• Swazz Javascript Calendar
• DateChooser
• Fancy MooTools Date Picker

I’ll keep extending this list as I find more and as I’m pointed to more.

Michael Grosser has created jqUnit for jQuery unit testing. I haven’t used it yet, but it looks promising. I’m working on a large jQuery-based project and I’ll try to report on how well jqUnit works.

John Resig, creator of jQuery, blogged today that he is participating in what I’d call the Panel of Century, if you’re interested in JavaScript libraries, of course. People from Dojo, Scriptaculous and Prototype will be joining him. But I won’t be there. Sigh.