Going off the rails

Firstly, allow me to state some facts. Rails is a really good framework for Ruby. Prototype, the JavaScript framework that comes with Rails, is also really, really good. The problem lies with the intersection of the two.

Dan Webb points to the problem. In Rails, you can add JavaScript helpers to your links, simply and easily. But those helpers then create redundant links (a href="#") with inline event handlers. As Dan quite rightly asks:

What happens when the user doesn’t have a new browser or has script disabled? What do search engines index?

Those are pretty fundamental questions.

David Heinemeier Hansson responds to Dan’s post, saying:

I’ll trade purity in HTML for purity in .rhtml any day of the week.

I couldn’t disagree with this sentence more. I’m all for making the developer’s life easier but when convenience for the developer is valued above ease of use for the end user, your priorities have become seriously messed up.

Fortunately, a solution should be forthcoming. Dan is working on a patch. Also, I remember talking to Dunstan when he was working on Odeo, another Ruby on Rails application, and, with a little bit of hacking, he was able to get the JavaScript to behave. That does prompt the question, though: if it is possible to have Rails produce unobtrusive JavaScript, why doesn’t it do so out of the box?

It may sound like I’m picking on Rails here, which isn’t my intention. On Wednesday, I listened to David outline the benefits of the framework and it was very convincing. But it’s precisely because Rails is built upon the ideals of best practices and doing the right thing that it pains me to see it fall short of those goals in this one area. After all, it doesn’t surprise me in the least that the ASP.NET framework spits out the most awful obtrusive JavaScript, as Stuart noted:

There’s a huge __VIEWSTATE form variable, and links seem to call a JavaScript function called __doPostBack(). Of course, it requires JavaScript to work. This is shit. Yes it is.

It’s kind of like Google and Microsoft: nobody would bat an eyelid if Microsoft censored search results in China, but when a company with the ethos “don’t be evil” does it, they are quite rightly held to a higher standard. So, if I seem to be unfairly singling out Rails, that’s just because it’s held to a higher standard.

Posted by Jeremy on Monday, February 13th, 2006 at 9:49pm


This is an important issue not just for developers who care about the "purity of their HTML," but also, as Dan is suggesting, for people contributing content in application spaces that need to be indexable by search engines at Yahoo, Microsoft, and…oh, drat…what’s that other one? The machine has become a crucial part of our audience, because the way the searchbot reads our text determines to a lare extent whether we get access to a human audience; search has become the principle gateway to edge content, and we depend on simple, machine-readable HTML to help searchbots help readers find the creative work we post in "edge systems" (many of which, for good reason, are written in Rails).

Most of the people creating content at the edge don’t fully understand the nuances of audience-acquisition in the Googleocracy…it’s up to developers to make sure that this is as straightforward as possible.

# Posted by Eric Miraglia on Monday, February 13th, 2006 at 11:01pm

Your analysis is spot-on. I frequently use bits and pieces of Prototype unobtrusively (in both static and dynamic environs), and I am similarly disappointed by Rails’ kludgy JS helpers. I won’t presume to scoff at how "easy" this would be to implement, but I will look after this patch-effort with great interest.

# Posted by Daniel Stockman on Tuesday, February 14th, 2006 at 12:13am

As I voiced on Dans comments I have the same issue with that as well. Again I like rails but it’s fabled speed seems to be, in a few places, aimed more at rapid prototyping (not the JS library!) apps than building the finished thing. The latter taking more time than you might think.

And dont even mention the hideous linkButton asp.net control.

# Posted by Gareth on Tuesday, February 14th, 2006 at 1:57pm

I hope that your patch can be absorbed by DHH into the rails tree, and they can make an effort at truly having good javascript support.

# Posted by JohnO on Tuesday, February 14th, 2006 at 2:02pm

Hey guys. It’s great to see passion around wanting to improve the use of Javascript in Rails. Love it. But let’s keep beans and apples in separate pots. The Javascript helpers does nothing to prevent you from writing machine-readable HTML that’s easy to index and to provide script-powered ahrefs that also serves as normal links.

The charge is that Rails uses inline JS calls in the onclick, onsubmit, and other triggers. This does nothing to change the structure of the document (there’s no superflous tags or forcing of specific tags), but it does indeed lead to verbose attributes of said tags with that inline JS stuff.

So this is a matter of purity of the resulting HTML for the human eye. Nothing more. Mind you, though, that I care deeply about the beauty of code to the human eye, so I can most definitely sympathies with people desiring that the generated HTML be beautiful too. Which is of course why I say: Rock on!

But let’s be sure to keep things in perspective. There’s no need to pad the argument. Desiring beautiful HTML purely for aesthetic reasons is plenty motivation to attempt to improve ;)

# Posted by David Heinemeier Hansson on Wednesday, February 15th, 2006 at 5:34am

David, no, you’re missing the point. This isn’t simply a matter of aesthetics, it’s a matter of accessibility. The fact that the JavaScript helpers add inline event handlers isn’t itself the problem: the bigger issue is that the links are completely useless without JavaScript (they use href="#").

This is about far, far more than "a matter of purity of the resulting HTML for the human eye." As Dan asked, "What happens when the user doesn’t have a new browser or has script disabled? What do search engines index?"

That’s where the JavaScript helpers could be improved. If they could add JavaScript as a progressive enhancement, then the functionality would degrade gracefully.

If this really were simply a matter of HTML purity, then I would agree that it would be relatively unimportant. But that’s not the issue.

For a quick primer on the concept of unobtrusive JavaScript as it relates to graceful degradation — and without wanting to hijack this into pimping my own kool-aid — you can read the sample chapter from my book, which covers this very topic:


# Posted by Jeremy Keith on Wednesday, February 15th, 2006 at 10:03am

Looking at Basecamp’s HTML this was the one thing that gave me pause for thought - I’m glad to see you highlight this issue Jeremy.

While David may be right that Rails doesn’t prevent the better way of doing scripting, it certainly isn’t the convention, it would be extra work. David knows how important conventions are and should work accordingly.

Rails has a lot to recommend it but they really need to practise what they preach with the use of accessible JS - onClick is just so last year.

# Posted by Jason Kitcat on Wednesday, February 15th, 2006 at 3:12pm

Indeed, href="#" is an accessibility nightmare. I mean, who cares (at this point) if JavaScript is inline. Yes, unobtrusive would be ideal at its best, but it’s not like we can achieve the accessible webpage via this.href from an onclick event handler directly on the anchor element. But for the record, I did not directly advocate the use of inline JavaScript, I’m just saying it can still exist and not screw accessibility.

# Posted by Dustin Diaz on Sunday, February 19th, 2006 at 3:15am

I noticed IconBuffet (a RoR app), uses accessible AJAX links. Even though the javascript is inline, it at least degrades nicely when scripting is not enabled. This behavior should be the default in Rails.

# Posted by Brian Sweeting on Wednesday, March 1st, 2006 at 5:58am

Sorry. Comments are closed.

February 2006

Recommended Reading

XML Subscribe

Grab the RSS feed for this blog.

JavaScript API

Grab the RSS feed of comments for this entry.