Today is a good day to code

Safari 2.0.4 Doesn’t Support javascript://return%20false

Posted: December 31st, 1969 | Author: | Filed under: Uncategorized | 1 Comment »

Safari 2.0.4 Doesn't Support javascript://return%20false

Picture of IrvinIn working on a project recently, a co-worker found, while debugging Safari that the return false trick doesn't work. I still have to check Safari 3, but as I remember it works well on Safari 3.

For those of you who don't know what I am talking about, let me enlighten you. The process of writing unobtrusive JavaScript is a process in enabling the rich potential of AJAX, without breaking the experience for Web 1.0 users who may not have JavaScript. This keeps your site compatible with most browsers, and crawlable by Yahoo! and Google. So unobtrusive JavaScript has many facets, by the one I am speaking of currently is having a solid-state clickable rel=”nofollow” href for your ajax actions, as well as utilizing the onclick or onmouseover event triggers. One way of doing this is to apply the onclick if the client supports JavaScript, and applying the href if they don't. This is best done on the server-side, but one problem is that if you make a mistake your client could get the wrong experience, another is that in HTML, the a tag must have an attribute of href to validate. That being said, your site won't properly validate if you don't have the href.

Many people just put a # symbol in the href, like:

but the problem with this is that whenever a user clicks the link, it will scroll to the top of the page, since # is the URL for an anchor, and # with no ID after it is the URL for the top of the page. This is a usability nightmare, unless your page is a fixed height.

What I, and many other developers have found is if we change the onclick a little, we can get the page to not scroll…

That fixes the scrolling problem in most browsers since the a stops being processed after the return false. To make this link unobtrusive, we would have to have a solid-state, Web 1.0 way to handle this action.

In the example above, there are two ways to handle the action. No one gets left out. The browser will perform the onclick first, and if it supports JavaScript, it will never get to the href. If the browser does not support JavaScript, the href will fire, it will ignore the onclick. It seems like a perfect solution.

But, alas… Safari 2.0.4, or the version shipping with Tiger, does not support this. It continues to process the href, most of the time, with or without the onclick. This problem was difficult to track down since if the JavaScript function contained in the onclick throws an error, the browser will continue to the href. This is normally desired behavior in an unobtrusive application, because an error could be an indication of limited JavaScript support.

Hopefully Apple will fix this with Safari 3, and they seem to have, but we will have to check for Safari, and remove the href server side, until everyone is running Leopard.