Baby steps: starting with jQuery - part 1

Messy JavaScript

I'm not exactly a stranger to JavaScript but I haven't used it much lately. Mostly, that's because my main use has always been writing (Windows) system utilities and application scripting (often in combination), and I with my current focus totally on the web just don't do that any more; I used it a little for some (by now) old web sites, but very sparingly — first, because I've always been concerned with keeping things accessible (and JavaScript was a definite hurdle then), and there was just too much playful JavaScript nonsense about, and too little really useful things. And writing JavaScript was messy, and became even more so as soon as other browsers than Netscape began to implement JavaScript, or their own versions of it.

Better JavaScript

But, things have changed in many respects. We have a real standard now (never mind that there still are proprietary implementations), and a bunch of JavaScript frameworks have sprung up that will hide the complexities of writing cross-browser code from you. And accessibility technology has become more aware of JavaScript (not merely ignoring it now), and thanks to ARIA even ajaxy pages can be made accessible. Juggling all of those (standards, browser implementations, frameworks and accessibility) is still complex and sometimes messy, but there's a world of difference with even just a few years ago. I started looking at frameworks, and generally following developments and bookmarking pages (jQuery, especially, appealed to me as a framework, and unobtrusive scripting, separating content and behavior, made as much sense to me as separating structure and presentation: it has been possible for a long time, but took off only a few years ago after some people showed the way).

So what have I been waiting for?

I need a real reason for JavaScript

Simple: a real reason to actually use JavaScript. More about that reason later (it will be the subject of a separate post), but ironically it's the same reason I implemented my first-ever bit of JavaScript in my first-ever website — way back in 1997. JavaScript, because there are some things you just cannot do with HTML alone or even with server-side scripting, and breaking out of a frame is one of those things.

But breaking a page out of a frame imposed by another website is trivial with JavaScript. The basic approach (there are many variations) goes like this:

  1. <script type="text/javascript">if (top !== self) top.location.href = document.location.href;</script>
This detects when (hierarchically speaking) the top-most window (frame) is not the same as the current page (in other words, this page is wrapped in a frame), and in that case simply loads the current page in the top-most frame. Simple and effective in most cases. So what's wrong with it?

Don't forget the visitor!

Not many sites discussing framebreakers mention an important usability issue that soon became apparent even way back in 1997 when we discussed them on the (then) CompuServe Internet Publisher's forum (aka INETPUB): what if the visitor did not actually mean to go to your site (framed or not)? Redirection is immediate and if the visitor hits the Back button they'll be redirected right back again so they end up being annoyed by your site rather than the framing site. An alternative is to replace framing site's URL with your own in the browser history: the visitor can then easily get back past the framing site, but still not to to the framing site, though she may have a good reason to do so. The solution is to build in a little delay, so there is time to follow a link on the framing site, or hit Back once more to go past it. This is used in the "framebuster" script as it's currently still implemented on an old site of mine (which was being framed by sites "linking" to it!):

  1. <script type="text/javascript" language="JavaScript">
  2. <!-- Hide script from older browsers
  3. setTimeout ("changePage()", 3000); // allows some time for hitting the Back button!
  4.  
  5. function changePage() {
  6. if (top.location.href != self.location.href) {
  7. top.location.href = self.location.href;
  8. self.onerror = null; // prevent error messages from browser that does't understand
  9. }
  10. }
  11. // end hiding contents -->
  12. </script>
This gives the visitor three seconds to find another link on the framing site (or hit Back again), and prevents spurious browser error messages as well. So what's wrong with it?

Another user-friendliness issue is what: the visitor may now be able to bow out of going to your site if that wasn't the intention, but even if it was the intention, is confronted with a sudden page reload and changed appearance — but why? That isn't made clear. Not very nice. The Wikipedia framekiller page rightly points this out and lists a variant that shows an alert telling the visitor what's going to happen. So that's great — or is it? Alerts are annoying, require a click (or hit Enter) to get rid of, and thus most people really hate these alert popups. So now the visitor knows what's going to happen, and why, but is still annoyed with our site instead of the framing site. It's the right idea (informing our visitor) but entirely the wrong solution.

Time for jQuery!

At this point I saw a little job for unobtrusive JavaScript and jQuery coming up: rather than displaying an alert, build a message "box", fade (or slide) it in, leave it up for a little delay (enough to read the explanation), and then remove it again before finally redirecting to put the page in the top-most frame. While the message box is showing, the visitor can still Back out of the (framing) site, and we can allow dismissing the box with a mouse click or keystroke as well to speed up the redirect if the visitor has seen it before, while still allowing to click outside of the box on another link. Or — unlike with the alert popup — sit back and do nothing. And all this should of course be done totally unobtrusively, by merely linking to some JavaScript files from the <head> element, and no further changes to any of the existing HTML: the body stays untouched. Just the thing for jQuery, in other words. Time to dust off my jQuery bookmarks, find some examples, and get my hands dirty.

Other parts in this mini-series:

0 Responses to Baby steps: starting with jQuery - part 1

  1. There are currently no comments.

Leave a Reply


Some HTML allowed (like a, em, strong, pre). If you want to embed a code fragment, its syntax will be highlighted if you surround it in pseudo-tags like this:
[geshi lang="php"]echo 'highlighted code!';[/geshi] (instead of using pre); specify language in the lang attribute. Do not enclose your code in tags like <?php … ?> as that will make it disappear.