Koz, thanks for the statements.
> I'll probably get in trouble for this, but I don't think that > unobtrusive javascript has yet to obtain the status of undeniable best > practise that you seem to be ascribing to it. The current helpers are > a pragmatic solution to what is otherwise an incredibly frustrating > job, and the code they generate may be 'obtrusive' but it works just > fine. You're probably right about getting in trouble, I already feel the accessibility folks will come kicking and screaming if they hear about this! ;-) But seriously: A little proactivity wouldn't hurt here - after all, Rails also created the whole Convention Over Configuration buzz, wasn't it? It may well be that it can also give birth to a _real_ unobtrusive javascript movement that really influences the way people think about accessibility. > The specific case you mentioned in your patch sounds interesting but > I'm not sure that the assumption of being able to make non-AJAX to the > ajax url is a valid one. <a href="/people/1"> isn't the same thing as > a link which submits a DELETE request to the same URL. Absolutely right. As I said, I wrote the patch and the short post that goes with it a couple days ago and reflected on it before starting this discussion. I mentioned in my first post here that the programmer should probably get an error message or at least a warning when trying to use a "harmful" method such as delete in a link_to_remote because it really should be a button (i.e. a form). If you can safely assume that POST/PUT/DELETE are always handled by forms, pages generally degrade more gracefully for people with JavaScript disabled. With the current way, it doesn't - if you have a link with POST/PUT/DELETE and a standard-REST action (e.g. /users or /users/1) it won't work with JavaScript disabled. Instead of POST /users, people will get the index action, and instead of PUT/DELETE /users/1, people will be given the show action. > What are the current practical problems which the existing helpers cause? I think it's not so much a practical problem. IMO it rather is one of those "little big problems" on a higher level. Little story from one of my projects here: I'd tell the client that I'll prepare a little prototype for them to see where we are going. They'll then try the prototype and ask "Why doesn't delete work? It always shows me the product page!". Well, guess what - they had JavaScript disabled. When I told them to enable it because the prototype needs JavaScript enabled, we got into a mini-fight about this because one of the requirements for the projects was that the page should degrade gracefully for people with JavaScript disabled. As I said earlier, it's not so much about the current functionality being a problem but more about the (IMO) better solution standing right in front of us and (so far) being ignored. > I strongly disagree with this, while it may be satisfying to feel > superior about people finding it hard to get started, that's not the > way successful communities behave. The barriers to entry should be > *lower* not higher. I knew while I was typing that very sentence that I might get in trouble for saying it or at least kick off a discussion because what I said can easily be misunderstood. I had already written an answer to that one but I've deleted it a few seconds ago to not kick of the argument about that because I think the matter at hand is way more important than the question of how high or low the barriers of entry should be! ;-) Cheers, - Clemens --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
