Edit: As Oskar points out, the MooTools can be more concise, so I’ve updated the code!Thanks Oskar!

So I’m a fan of unobtrusive javascript – that means I like avoiding “onclick”, “onblur”, “onfocus” etc. etc. I don’t like doing “href=’javascript:dostuff();return false;’”. It makes me cringe – in this day and age, everyone has their favorite javascript library, and they make event delegation damned easy to the point that I have to ask – if you load a javascript library on your site, why not use it?

Print this window!

Generally, those “print this window” links tend to be something along the line of:
<br /> <a href="#" onclick="window.print();return false;">Print this window</a><br />

or even:
<br /> // ewwww javascript in an href?<br /> <a href="javascript:window.print();return false;">Print this window</a><br />

Why do it this way? Why create a link that may not work?

The MooTools way:

MooTools is my rifle – I tend to focus on it first and foremost when it comes to thinking about UI.

Let’s take a “Print this Window” link and add a CLASS.

<br /> <a href="#" class="print-window">Print this Window</a><br />

Why CLASS over ID?

This is a valid question – some people like having things spelled out down to the letter, and they like their specificity. MY concern here is (recently) a client had a “print” link at the top and bottom of an overlay – IDs become invalid! So I prefer to keep that in mind at all times and code accordingly to the “what-if” scenario:

<br /> $$(‘.print-window’).addEvent(‘click’,function(e){<br /> new Event(e).stop(); // if you code your print link as a link, this basically does the same as “return false;”<br /> window.print();<br /> });<br />

ZOMG! So easy! And it’ll hit EVERY class with “.print-window”! This method will hit ALL elements, so you may want to tighten it up a little bit:

<br /> $(‘container’).getElements(‘.print-window’).each(function(el){<br /> el.addEvent(‘click’,function(e){<br /> new Event(e).stop(); // if you code your print link as a link, this basically does the same as “return false;”<br /> window.print();<br /> });<br /> });<br />

Now, why not search for “a.window-print”? Why use an “anchor” if it’s not going to be used?

To be honest – you don’t have to use an anchor. The class name is what’s important – you can make it a <span> if you don’t like using <a> or simply attach it to an image.

jQuery “Print this Window”

<br /> $(‘.print-window’)<br /> .click(function(){<br /> window.print();<br /> });<br />

Simply delicious! You may need to double check me on that – jQuery is my backup, the dillinger to my glock.

What if javascript is not enabled?

Gasp! The horror!

No doubt this is something that may need to be accounted for – and I’m all about accounting for it all. This also brings up the question – do we care if search engines see it? Are google searches for “print window” a maker or breaker? Really, for our purposes, they’re a “nice to have” function that adds no real added value to our page, and if you don’t care if a search engine sees it, there’s more than one way to jam this tune out.

For this, I like to use javascript to inject the elements in the page – javascript is needed to USE the link, so why not use it to make it available?

For this, it could be as simple as using CSS to HIDE the links, and javascript to SHOW the element, or you could go a step further and generate the images via javascript to begin with!

It’s kind of a pandora’s box – use with care!

“Power tends to corrupt, and absolute power corrupts absolutely. Great men are almost always bad men.”

-Lord Acton, in a letter to Bishop Mandell Creighton, 1887

I’ve noticed a disturbing trend that I myself have fallen victim to. I’m seeing sites coded where we do more in javascript for our styling needs and interaction, with no fall back support for non-javascript users. Styles are called explicity from javascript (which requires a lot of transversal to find out “is it this #000 or that #000?”). onclick events. Onblur. Really?

Use the power of your framework!

Don’t do the work if you don’t have to!

For example, mootools allows us to grab any item on the page and add events to it:

[sourcecode language='javascript']
$$(‘a’).addEvent(‘mouseenter’,function(e){
alert(‘you entered the anchor!’);
});[/sourcecode]

Why stop with one event?

(straight from the mootools documentation!)

[sourcecode language='javascript']
$(‘myElement’).addEvents({
‘mouseover’: function(){
alert(‘mouseover’);
},
‘click’: function(){
alert(‘click’);
}
});[/sourcecode]

Using mootools we can make our code totally unobtrusive. No more onclicks littering the pages. We can leave the HREF tag pointing to static pages. We can inject elements on teh fly, so if someone doesn’t have flash/javascript we don’t show certain elements:

[sourcecode language='javascript']
// don’t have flash?
if(Browser.Plugins.Flash.version !== 9) {
// hide stuff!
$$(‘.flashNeeded’).setStyle(‘display’,'none’);
// show stuff!
$$(‘.noFlashNeeded’).setStyle(‘display’,'block’);
}[/sourcecode]

But not to forget our jQuery bretheren (we’re all one big family)…

Let’s do the same in jQuery!

[sourcecode language='javascript']

// single event
$(‘a’).mouseover(function(){
alert(‘you entered the anchor!’);
});

// multiple events
$(‘a’).bind(‘focus’, function(){
alert(‘focused!’);
}).bind(‘mouseover’, function(){
alert(‘moused over!’);
});[/sourcecode]

jQuery doesn’t do Flash out of the box…

At least, I can’t dig it up – but that’s not a bad thing!

The users of jQuery (A hearty, formidable group) have created the jQuery plug-in to detect flash versions!

It’s all a matter of preference and opinion and bias as to whether it should be included with the main library or not.

The Framework Wars are dead.

We see similar abilities in all the frameworks – and instead of bickering about “being the best” we should work on contributing and learning these frameworks.

Toby Miller put it best – “One framework at a time, please!”

One framework at a time, please!

You wouldn’t hand-over JSP code to a PHP client, would you?

I really hate stumbling on sites that think just because there is a “no conflict” version we should just jam as many frameworks together that we can. That, to me, defines a lazy developer. I fight that battle – instead of being lazy and saying “I know this one better, so let’s turn no-conflict on” we should instead be saying “the client uses library X so we should develop accordingly – even if that means learning a new code!