DOM Scripting comments: Going off the rails http://domscripting.com/blog/display/49 Rails is great, but why, oh, why does it add obtrusive inline event handlers? en Brian Sweeting http://domscripting.com/blog/display.php/49#comment255 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.

]]> Wed, 01 Mar 2006 05:58:44 GMT Dustin Diaz http://domscripting.com/blog/display.php/49#comment254 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.

]]> Sun, 19 Feb 2006 03:15:15 GMT Jason Kitcat http://domscripting.com/blog/display.php/49#comment252 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.

]]> Wed, 15 Feb 2006 15:12:36 GMT Jeremy Keith http://domscripting.com/blog/display.php/49#comment251 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:

http://domscripting.com/book/sample/

]]> Wed, 15 Feb 2006 10:03:15 GMT David Heinemeier Hansson http://domscripting.com/blog/display.php/49#comment250 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 ;)

]]> Wed, 15 Feb 2006 05:34:23 GMT JohnO http://domscripting.com/blog/display.php/49#comment249 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.

]]> Tue, 14 Feb 2006 14:02:53 GMT Gareth http://domscripting.com/blog/display.php/49#comment248 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.

]]> Tue, 14 Feb 2006 13:57:39 GMT Daniel Stockman http://domscripting.com/blog/display.php/49#comment247 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.

]]> Tue, 14 Feb 2006 00:13:17 GMT Eric Miraglia http://domscripting.com/blog/display.php/49#comment246 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.

]]> Mon, 13 Feb 2006 23:01:14 GMT