Of course, I’m not actually talking about bakery; I’m talking about the web, and the many layers that it’s made of. I believe that maintaining separate layers is the best way to move forward whilst offering a usable, functional and accessible web.

I think JavaScript is an afterthought, and I think it’s best for everyone if it’s treated that way. Once you try mixing it into your application you’ll eventually encounter a conflict of layers! A.K.A pissed off users.

I’m not just talking about being unobtrusive; I’m talking about true progressive enhancement, and true separation of concerns, on the server side and on the client side. I appreciate and try to develop by this ideal, because I honestly feel that it is the best way to develop any website or any application.

It’s not just about the end-user experience though; it’s about developing in a way that makes sense. For me, this makes sense.

For me, until I change my mind, JavaScript will always be the icing on the cake!

An example of this:

$('tr').bind('click', function(){
    window.location = 'http://somelocation.com';
    // Or, we can grab the HREF from the first anchor:
    // window.location = $('a:first', this).attr('href');
});

This might be deemed suitable by most but, truth be told, it’s an almost pointless enhancement. The same is true for any attempted link simulations. For example, having a DIV element and making it re-locate the page upon a click. Doing this is pointless because it’s not a real link! Browsers offer a bunch of behavioural enhancements to anchors, for example:

• Middle-click: Page opens in new tab.
• CTRL/SHIFT click: Page opens in new window/tab.
• Right-click options: “open in new window”, “copy link location” etc.
• Status message is changed to the HREF of the anchor.
• etc…

It’s impossible to simulate all of the above. Users are left confused and sometimes annoyed when an element doesn’t act like it’s supposed to…

There are no rules that state that table rows or DIV elements cannot be clickable but if you’re going to do so then it’s important to preserve what functionality is expected from anchors. Of course, most users don’t think of them as “anchors”; they’re just links to other pages, but even so, users have a set of unwritten expectations which dictate how websites should behave.

In other words, if you’re going to make an element function like an anchor then it must be an entirely accurate emulation.

So I thought, instead of trying to simulate the expected functionality I could instead simply create an absolutely positioned anchor that moved with the cursor; this anchor would only be activated when the corresponding table row was being hovered. And since it’s a real anchor, all expected functionality is present, including those behavioural enhancement offers by the browser. This is the answer I originally posted on the thread at Stack Overflow.

Then I had another thought; instead of having to update the anchor’s position whenever the document’s mousemove event triggered, I could just keep it statically hovering over the table row; like a blanket.

I decided to create a jQuery plugin utilizing the above technique:

• See the code!
• See the demo!

It works on any element that contains a link. The plugin takes one argument; the selector to target the link within the container, which, by default, is ‘a:first’.

Note: If you plan on binding mouseover/mouseout events on the same element that the plugin is running on then make sure to bind both events BEFORE calling the plugin. Also, don’t use mouseenter/mouseleave events – the mouseleave event won’t occur as expected because of the anchor overlay.

Using the plugin is dead simple; say, for example, you have a table with multiple rows; each row has an anchor within the last cell <td>:

$('table#mytable tr').superLink('a:last');

Now every row will seem like one giant anchor to the user!

As per the details digressed in the mentioned report I have created a jQuery plugin which deals with this issue. By implementing the following enhancements, the plugin ensures your users a visit worth remembering!

• Continuously varying textual colour makes words easier to focus on while progressing through any particular sentence.
• In addition, constantly changing background colours ensure the necessary inconsistency when reading text. As mentioned in the report, contrast is of central importance, – this is integrated into the plugin.
• Whenever a word is hovered over, the report states that the user must be looking for a deeper meaning – to fulfill this need the word in question is subtly re-sized.

You can experience a fully working demo over here. If you are epileptic please don’t visit this link: THE DEMONSTRATION

This plugin is very easy to integrate. Just call the “readability” plugin like so:

$.rEaDaBiLiTy();

Once initiated the plugin will automatically enhance the page in the ways mentioned.

Readability isn’t something to be taken lightly, it’s a serious issue and has been known to have widespread lethal affects across the globe. Web designers and developers have advanced recently in this area but the job isn’t yet done; we have to push for absolute readability. This plugin is only a tool, a tool to enable the world to get that one step closer to an entirely readable internet!

Please consider donating as I had to scour the entire WSA’s report just to uncover the key to readability. The plugin took a considerable amount of time to develop; throughout its creation I continually became parched and/or hungry so please consider buying me whatever you can afford (i.e. this). Thank you for supporting me!

UPDATE: APRIL FOOLS!!!

Unfortunately, and quite predictably, its usage has spread massively, but not in the right direction. Nowadays, it’s used to counteract the pain of having to deal with CSS specificity, otherwise known as the set of rules which dictate that “div h1 a” is more specific selector than “div a”. Most people that use CSS on a daily basis don’t know enough about CSS specificity to solve their problems without using the “!important” suffix.

For reference, “specificity” is the name given to signify the precedence of a particular CSS selector. Here’s a quick rundown:

*             {}  /* a=0 b=0 c=0 -> specificity =   0 */
LI            {}  /* a=0 b=0 c=1 -> specificity =   1 */
UL LI         {}  /* a=0 b=0 c=2 -> specificity =   2 */
UL OL+LI      {}  /* a=0 b=0 c=3 -> specificity =   3 */
H1 + *[REL=up]{}  /* a=0 b=1 c=1 -> specificity =  11 */
UL OL LI.red  {}  /* a=0 b=1 c=3 -> specificity =  13 */ 
LI.red.level  {}  /* a=0 b=2 c=1 -> specificity =  21 */
#x34y         {}  /* a=1 b=0 c=0 -> specificity = 100 */
 
/* Source: http://www.w3.org/TR/CSS2/cascade.html */

The specificity is calculated as follows:

• count the number of ID attributes in the selector (= a)
• count the number of other attributes and pseudo-classes in the selector (= b)
• count the number of element names in the selector (= c)
• ignore pseudo-elements.

(read more about it: http://www.w3.org/TR/CSS2/cascade.html#important-rules)

The power of CSS and its cascading nature, in my opinion, is only fully appreciated when one understands specificity. A lack of understanding only leads to bad practices, such as using the “!important” suffix. Of course, it’s not always a bad idea, sometimes it’s necessary; for example, the Google toolbar in browsers always insists on colouring certain input fields yellow to signify that an ‘autocomplete’ feature is available. To be blunt, this can make your design look crap! The only way to counteract this is to define an “!important” style, i.e. the only thing more specific than inline styles.

Apart from a few edge cases its use is, in my opinion, unfounded and mostly unnecessary. Not to mention the fact of how annoying it is for a user when they want to apply their own styles or enhancements; you better have a damn good reason for relinquishing such a rudimentary level of control!

The only thing that can override an “!important” rule is another one, which must be specified lower down and its selector must have the same (or a higher) level of specificity. You can also specify “!important” styles inline. Another method would be to remove the rule entirely, this can be achieved with JavaScript, by accessing and manually removing the rule in question: http://dev.opera.com/articles/view/dynamic-style-css-javascript/#addingandremovingrules.

Even though there are solutions, it is still a massive pain for users, so please, don’t use “!important” unless you have no other option!

When is too much? …

Story time…

I recently was revising for an upcoming driving theory examination. To revise I was issued with a piece of software containing various mock tests and the Highway Code. The only thing wrong with the entire application was the damn navigation. Every time I returned to the top-most level of a topic area it took about 5 seconds (yes, that is a long time) for the menu to animate on to the screen. The most useful menu-item happened to be at the bottom of the menu and so every single time I wanted to click it I had to wait 5 whole seconds after arriving on the page!

A couple of years ago I would’ve really appreciated a slowly cascading menu but nowadays it’s just incredibly annoying because I have to wait until the very end of an entire animation until I have full access.

You know what the real problem is? It’s some over-zealous programmer or designer who thought it would be cool to have something whizzing or popping on to the page. If it’s not them then it’s their managers or perhaps it was the bloody client!

And that’s not the only time the obvious over-zealousness of a “professional” has pissed me off: To aid me further in my driving theory preparation I decided to purchase (and not cheaply, I might add) an application for my iPod Touch which also contained mock tests and the Highway Code. After testing it out for the first time I was quite satisfied. But again, because of some crappy developer, the software frequently screwed up on itself because of an intentional feature. The hotshot app developer thought it would be cool to add a ’shake’ feature so when a user reaches a question in one of the mock tests they have the option to skip it by shaking the device.

I had previously read about this feature in the iTunes store; I thought nothing of it at the time. It was only when sitting in the back of a car, being driven at a regular speed, trying out a mock test that the app suddenly skipped three questions in a row. The app offers no way to go back a question so that really sucked! I mean come on! What the **** is the point in adding a ’shake’ feature? It’s one of those, “I’ll add this feature to show how cool a developer I am” – normally I’m actually okay when people show off, but when it effects the usability or usefulness of a product it’s simply not acceptable!

Now, what does that last story have to do with animation? Well, that idiot developer thought it would be cool and obviously didn’t think much past that. It would be nice if people would consider coolness as a lesser priority than something like usability.

So…

When you’re thinking of adding any animation to anything on a website, even if you’ve been ordered to do so by a boss or client, always think about usability…. always, always, always think about the user! Nobody is going to be impressed if your steaming animation impedes process! Don’t impede or delay the process of an application or website, ever!

By “process”, I mean the normal and anticipated manner through which a user may interact with your application or website.

Oh, also, I really really hate Flash! If you’re still using flash to develop websites then the only acceptable excuse is that you’ve been in a coma for about three years! FLASH SUCKS! I don’t give a damn about “immersive experiences” when I’m surfing the web, all I want is my damn information!

JavaScript; jQuery, MooTools etc.

Evident from my above ramblings, the line between ‘quite pleasant’ and ‘inconceivably annoying’ is very thin! Don’t go crossing it with a JavaScript framework! – That’s not what they were made for!

I am also at fault; I have also succumbed to the idiocy of the collective. But I have learnt my lesson and have vowed to myself that I will never [consciously] do it again.

Lesson learnt: Don’t jump on the bandwagon just cos’ it’s shiny and faster than the other ones!

Even with getTimezoneOffset() you’re still relying on the client!

It turns out that the only way of getting a complete and accurate time from any timezone requires a little bit of server interaction. Luckily there are a few APIs out there that offer this service (actually, there’s only one; well I couldn’t find any others)!

Here we’re using the ‘json-time’ API developed by Simon Willson:

JSON-time

function getTime(zone, success) {
    var url = 'http://json-time.appspot.com/time.json?tz=' + zone,
        ud = 'json' + (+new Date());
    window[ud]= function(o){
        success && success(new Date(o.datetime), o);
    };
    document.getElementsByTagName('head')[0].appendChild((function(){
        var s = document.createElement('script');
        s.type = 'text/javascript';
        s.src = url + '&callback=' + ud;
        return s;
    })());
}

Usage

The first parameter of the callback function is the time (having been passed through the Date constructor), so you can use Date methods such as getSeconds() etc. The second parameter is the entire object returned from the JSON request.

// Alert GMT:
getTime('GMT', function(time){
    alert(time);
});
 
// Get London time, and format it:
getTime('Europe/London', function(time){
    var formatted = time.getHours() + ':' 
                  + time.getMinutes() + ':'
                  + time.getSeconds();
    alert( 'The time in London is ' + formatted );
});

For reference, here’s a list of all the available timezones (to use one, remove the backslash).

jQuery version

$.getTime = function(zone, success) {
    var url = 'http://json-time.appspot.com/time.json?tz='
            + zone + '&callback=?';
    $.getJSON(url, function(o){
        success && success(new Date(o.datetime), o);
    });
};
 
// Usage:
$.getTime('GMT', function(time){
    alert(time);
});

MooTools version

You’ll need to download the JsonP class.

function getTime(zone, success) {
    var url = 'http://json-time.appspot.com/time.json';
    new JsonP(url, {
        data: { tz: zone },
        onComplete: function(o){
            success && success(new Date(o.datetime), o);
        }
    }).request();
}
 
// Usage:
getTime('GMT', function(time){
    alert(time);
});

Thank you Simon Willison for making this API; seriously, I searched around the entire internets just for one damn API and I almost lost hope!

I’ve never surfed the web in a browser less capable than IE5, this should say quite a lot about my lack of understanding of less capable pieces of software and devices, yet, I still appreciate and understand that graceful degradation is of upmost important when creating any website.

Let’s look at your average out-of-college web designer’s perspective on graceful degradation, assuming they know what it means:

Note: When reading the below passage out in your head do it with an "Artful Dodger" (from Oliver Twist) accent; it’ll come across as more believable!

Some idiot:

"Look, mate, I’m NOT gonna build an entire website which validates, is table-less and has degrading JavaScript for any amount of money – that’s just stupid! Even if that 5% stat were true (I doubt it) I wouldn’t feel any different. Graceful degradation is an added feature; something which clients should have to pay more for! I make clients pay more for validation, table-less layouts, optimized images, IE6 support, IE7 support, Opera support, actually anything which isn’t Firefox (FF FTW!) I charge extra for! My approach is way more forward-thinking and innovative than those "standardistas"!! Who the hell gives a damn about some paranoid geek running Lynx to browse the web, and nobody even uses NoScript! If a user disables JavaScript then that user shouldn’t expect functionality, period! And as far as I’m concerned, if a user doesn’t have the very latest nightly build of FF3 then I’m not gonna cater to them!"

Why the idiot is wrong:

The above passage represents the complete and utter idiocy of some people, real people! You might think it’s a little over the top, what with the "if a user doesn’t have the very latest nightly build" comment but overall it is a pretty accurate depiction of what I fear a few web designers around the world actually think.

"Graceful degradation is an added feature"

This is an all-too-common misconception; if you think this is true then you’ve got it all backwards. In all this mess the only thing which is really an "added feature" is the JavaScript itself. The methodology which ensures degradability may be part and parcel with the JavaScript (as it should be!) but it certainly is not an added feature itself.

"If a user disables JavaScript then that user shouldn’t expect functionality, period!"

What you have to understand is that JavaScript and the extent to which it is supported is not always controlled by the user, there may be other reasons why your JavaScript enhancements cannot be experienced by them (look below), so don’t assume that your user’s have knowingly disabled JavaScript or that they even know what JavaScript is.

"Who the hell gives a damn about some paranoid geek running Lynx"

It’s not only the "paranoid geeks" who will have JavaScript disabled, there are many other valid reasons for JavaScript not working. Ignoring these users is selfish, against standards and is definitely a bad business decision!

Reasons for JavaScript being disabled:

• Security reasons. (to protect from XSS attacks and Internet Explorer’s multiple security flaws etc.)
• JavaScript slows down a user’s already slow dialup connection.
• Browser sometimes crashes because of excessive JS, user disables it.
• Popups, onBeforeUnload alerts, disabled right-click etc. – User get’s pissed off and disables JavaScript!
• User is disabled in some way and uses a screen reader such as JAWS, Windows-eyes, SpeakThis etc. (Each having no or limited JavaScript support)
• User is surfing from behind a corporate firewall – the firewall blocks client-side-scripting. .
• Very old browsers don’t support JavaScript.
• Mobile web browsers only have limited support of JavaScript. (‘Opera 4 mobile’ uses a proxy which strips out most JavaScript)

As you can see, it’s not just some people who disable JavaScript from within their browsers, there are a

Ensuring a degradable experience

In order to ensure a degradable experience for your users it’s important to have the right mindset from day one. Graceful degradation itself is really just an end to which the means is usually something called ‘progressive enhancement’, a well-known methodology used in building fualt-tolerant systems.

Progressive enhancement, when applied to the internet, is essentially the process of a website or web application functioning perfectly on modern software while still being able to work correctly on older software. When applying this concept to websites it’s easy to see it’s relation to the three layers of the web; content, presentation and behaviour.

Content is the fundamental backbone of any website; all your content should be visible whatever device or software platform a user is running. The content of your website will typically be found within the HTML, neither of the other two layers should be found within your HTML! Equally, your content should not come from either of the other layers. With the rise of multimedia (video/audio websites) this is becoming an ever unrealistic expectation but it’s good to have principles, right!?

Presentation (usually CSS) is the second layer and, for those browsers that support it, offers a lot of control over the layout and decoration of your content.

Behaviour (usually JavaScript) is the third layer of the web and should be the last thing to build within a project cycle. Only use JavaScript to enhance the user’s experience. By making a site’s functionality dependent on JavaScript you’re immediately cutting out a percentage of users.

Once you have your content in place you can work on the presentation of that content, and then after that you can start adding JavaScript enhancements.

Please note: I am talking about websites in this post, not web applications. Web Applications (many of which require JavaScript to operate) and the principles by which they’re built really have more in common with desktop applications than real websites. That said, it would be great if web application developers took a couple of the above points seriously!

Not only JavaScript…

The topic of this post does not only apply to JavaScript. Your content (HTML) and presentation (CSS) layers must also degrade in the same way. Nowadays most of the focus is on JavaScript because that happens to be the layer which most people screw up so frequently!

Checking if the DOM is ready

Running code when the DOM is loaded and ready for manipulation is a popular requirement. The ideal solution is to place all initiating code at the bottom of your document (as per Yahoo’s "Best Practices for Speeding Up Your Web Site") but sometimes this is not possible. The next best alternative is to use a solid ‘DOM ready’ function such as the one jQuery offers. You normally access it like this:

$(document).ready(function(){...});

There’s a quicker way of accessing the same functionality:

$(function(){...});

Creating elements

There are a few different ways of creating elements, this is my favorite:

$('<div/>').appendTo('body');

Alternatively you could take this route:

$('body').append('<div/>');

Notice that you don’t have to write out the entire element. Even though DIV elements cannot have self-closing tags it’s still fine to specify it like above – JQuery will know what you mean.

Adding or changing attributes in bulk

Not so good:

$('a').attr('id','mydiv');
$('a').attr('class','important');
$('a').attr('href','http://www.google.com');

Better:

// i.e. Chaining
$('a')
	.attr('id','mydiv')
	.attr('class','important')
	.attr('href','http://www.google.com');

Best:

$('a').attr({
	id: 'mydiv',
	class: 'important',
	href: 'http://www.google.com'
});

Have full control over your animations

jQuery’s stock animation functions such as fadeOut() and slideDown() can be useful but may sometimes do more than you intended (like setting the element to display:none; instead of JUST reducing the opacity). So if you want to have full control over your animations then use animate().

$('#elem').animate({
	// Reduce opacity by 0.2:
	opacity: '-=.2'
});

Three ways to test wheter an element exists

// 1:
if ($('#elem').size()) { alert('It exists!'); }
// 2:
if ($('#elem').length) { alert('It exists!'); }
// 3:
if ($('#elem').get(0)) { alert('It exists!'); }

Chain Everything!

jQuery gives you the power of chainability, this means you can perform multiple actions on a single element or set of elements without having to ‘re-select’:

$('<div/>')
	.css({
		cursor: pointer,
		height: '200px',
		width: '200px'
	})
	.attr({
		id: 'mydiv',
		class: 'box'
	})
	.append('<a href="#">link</a>')
	.appendTo('body');

Over the last year there’s been a major recognition boost for these libraries, especially those featuring animations/effects and Ajax capabilities. Blinking/fading/sliding text was in fashion back in the nineties but it seems, following the hype of Web 2.0, these effects have made a massive comeback!

To be honest I think it’s great; what better way to expand the imagination of the average developer than to give him/her some brand new toy to play with? Web developers are now thinking of innovative ways to utilise these new-found JavaScript enhancements and designers are pushing boundaries with their designs, integrating these enhancements into their mockups!

This is all wonderful, but unfortunately I fear the overuse of JavaScript libraries such as jQuery has had a detrimental effect on usability. Obviously we had issues before these libraries and we will surely continue to rave about it afterwards but I cannot help but notice what is happening right now; people are turning a blind eye to usability and focusing all their attention on making their websites as smooth and swish as possible!

If you’re in the template trading industry then you will have heard of the recent successful launch of ThemeForest, yet another powerhouse off the Envato production line. At the moment it has upwards of 300 templates for sale, ranging from Wordpress magazine-style themes to one-page portfolio sites.

Flicking through the templates on offer you’ll probably notice nothing wrong with what’s offered, even if you look at the previews of some of them you’ll notice nothing strange. But, if you continue you’ll eventually find a number of templates offering "jQuery effects" and featuring "Ajax pagination"! Both of these terms spark a lack-of-usability chord within me. Looking at the preview of these particular templates proves just how lacking the author’s knowledge of usability is. Even basic concepts like code validation and degradable JavaScript have been massively overlooked!

Yes, these templates look great when you’re using a modern browser like Firefox 3 and have JavaScript enabled. But what happens if you’re using IE6 without JavaScript? In fact, even using a modern browser, but with JS disabled is disappointing – for a couple of the themes nothing even comes up… not even a warning to say "you must have JavaScript enabled to view this site".

Why should these authors be allowed to make any money from their laziness? Template buyers are as clueless about the issues as the authors and so ignorantly give over the odd $15 for their new "premium" template, completely ignoring the fact that a large proportion of their users may be utterly disappointed!

One of the core values of jQuery is that it lends itself to unobtrusive JavaScript, thus promoting the ideals of progressive enhancement and graceful degradation, two terms that seem totally lost on some developers!

Contrary to the title of this post, the JavaScript libraries are not to blame; they’re merely making it easier to access JavaScript functionality so that people don’t have to spend hours developing it themselves. The problem lies in the ignorance and laziness of web developers!

Just to be clear, there is nothing wrong with ThemeForest itself, in fact it’s one of the best and probably the cheapest template-selling website out there. I only take issue with a couple of the authors – it seems they insist on making "cool" sites which totally lack many of the core and fundamental practices of the web!