External Relations, Business School, Curtin

jquery rollover via image swap

2009-07-03T11:26:00.002+08:00

Still on the theme of rollovers and keeping the js unobtrusive. On occasion our contributors need to plugin a rollover effect on an image. I wrote an accompanying js/jquery solution to unobtrusively seek out the rollover image, preload the active image and implement the hover function.

example http://www.business.curtin.edu.au/business/future-students (which course[yellow] and which career [red] buttons mid-right)

html:
<img src="/images/btn08-fs-which-course02-off.jpg" border="0" alt="Which course?" width="144" height="135" class="rollover" />

js:
/* create a lookback for js regex */
String.prototype.reverse = function () { return this.split('').reverse().join('');};

/* jquery inside $(document).ready*/
jQuery('[class*=rollover]').each(function(){
src_path = $(this).attr("src");
this.off = new Image();
this.on = new Image();
this.off = $(this).attr("src");
this.on = $(this).attr("src").reverse().replace(/ffo(?=(-_\.))/g, '!ffo-ecalper!').reverse().replace(/!replace-off!(?=((-_\.)))/gi, "on");
$(this).hover(function(e){
this.src = this.on;
},function(e){
this.src = this.off;
});
});

unobtrusive, dynamic image rollovers

2009-06-26T16:38:00.008+08:00

Rollovers are excellent usability/accessibility points. They let you know right away that this thing that changes when you go near it, is going to lead you somewhere. The problem is that the implementation doesn't fit in well with unobtrusive javascript implementation.

The solution can be quite simple when talking about navigation links or common buttons. ditch the javascript all-together because all you need is css.

This style solution is now common and based on the a:hover psuedo-class. It uses a background graphic displayed via the styling where the graphic shows both the on and off or hot and cold rollover graphic. The important factors here are that the A tag's display is only as tall as the half graphic height. This is taken care of by setting the height of the A tag to 18px where the rollover graphic's height is 36px. When someone mouses over the A link, the hover class kicks in and displays the background image starting halfway, so the top half (the off position) is hidden.

Lastly we want this to degrade nicely and read well for bots, so we place the actual link text in but obscure it.

Background-graphic:

html:
<ul id="navigation">&
<li ><a href="/some-link.html"><strong>Some link</strong></a></li>
</ul>

css:
#navigation{
height:18px;
margin:0;
padding:0;
list-style-type:none;
overflow:hidden;
}
#navigation li{
float:left;
}
#navigation li a,#navigation li a:hover{
display:block;
color:white;
padding:4px 21px 4px 20px;
text-decoration:none;
background-repeat:no-repeat;
height:18px; /* limit the A height to the first half of the graphic*/
background-position:0px 0px; /*set the background to only show the off graphic */
}
#navigation li a:hover, #navigation li.selected a{
/*on hover or selection, roll the background image to half it's height, revealing the 'on' version */
background-position:0px -18px;
}
#navigation li a strong{
visibility:hidden;
}

Example: http://www.business.curtin.edu.au/

Reducing js framework bloat

2009-06-25T12:14:00.002+08:00

There are few sites that can achieve a sexy js framework implementation without the assistance of further plugins. Many of my previous jobs required at least the inclusion of a validation plugin for contact form validation and a greybox plugin for viewing image popups.

As you would expect however, the majority of pages won't require all of those additional libraries so you end up with download and initialisation bloat. In small site implementations this can quickly be rectified by implmenting different js includes for different types of templates (although this becomes messy dealing with multiple external initialisation scripts).

On the business school website, there's no way of determining the uses of the page templates and therefore, no way of predetermining what js will be required. On interviewing for the job, I was told there were some 2 thousand pages in the subsite so the varition in usage is too high to try manual control of js. To try making all libraries available for all pages creates a js bloat of over 150kb which is too high. I decided to automate js to dynamically inject libraries if and when they are required.

code to dynamically inject the library if it's not already present:

function includeJs(file) {
var scpt = "";
// Handle multiple include attempts
if($("script[src='" + file + "']").size() == 0) {
scpt = $('').attr('type','text/javascript');
scpt.attr('src',file);
$('head').append(scpt);
}
}

code to call the library when needed:

//find all hyperlinks with .swf in their href
$('a[href*=".swf"]').each(function(e){
includeJs('/js/jquery.flash.js');
//further code
}

Unobtrusive javascript

2009-06-25T11:15:00.001+08:00

For years contributors have been posting javascript includes into their articles. The site is littered with invalid and sometimes broken includes to files that no longer exist, no longer support the architecture or are just plain old not needed anymore.

Step 1: Formulate a plan to pool all js requirements into a single updateable source.
Decision - Install a js framework library.

Step 2: Decide on an appropriate js library/architecture.
Decision - I chose jQuery, mainly because I've been using it for years and have found it to be the least bloated while offering the best degree of control with minimal lines of code. I've also tried a number of others such as Dojo and Scriptaculous, albeit in very early days. They weren't bad but suffered from being buggy or bloated or just lacking some functions I really needed (like a hover function)

Step 3: Streamline the implementation for best crawl-ability, validation and loadtimes
Decision - Remove all script from the page (unobtrusivity) and push it as far down the page as possible.

It's been common practice amongst many developers to implement all their js in the header block of pages. Traditionally this made sense because we wanted to be sure our js was readily available before we tried using it throughout the document. These days however this has become an unhealthy practice due to the bloat in js size (frameworks vs the old single use precedures). In page load terms, js hogs the download stream so nothing else on the page will download while js is coming down the pipe. This can be changed by adding defer="defer".

This is no longer appropriate however as js frameworks such as jQuery are instantiated using the document.ready protocol, so they'll only run once the document has downloaded and is displaying (usually this is the case but there's some discrepancy as to exactly when this init fires in different frameworks). So to the script tag download can be deferred by params but why bother? I've already identified that I want this to load last ... why not put it last?

Step 4: Calling the js
Decision - Install the minimum required.

There should be two inital js includes here; one to the base library and one to the document holding your library initialisation calls. Remember that we're pooling our js resources into a single point for easy updating. So our implementation methodology will be kept in an external file. I usually maintain two initialisation files, one public and one private for the CMS. In this case, I just maintain one, but the habit's still there.

<script type="text/javascript" src="js/jquery.min.js" defer="defer"></script>
<script type="text/javascript" src="js/public.js"></script>
</html>
</body>