HTML5 classList API

html5 classList

DOM element class attributes are not only used as ‘hooks’ in CSS to create selectors by which developers and designers style pages, they are widely used in JavaScript for DOM programming. They are an integral part of front-end web development, and used by developers on a daily basis.

Hitherto, working with classes natively has been arduous. This has contributed to the rise in popularity of libraries that provide helper methods. jQuery for example, provides addClass(), hasClass(), removeClass(), and toggleClass(). These methods make working with classes a breeze. Surely, these methods should be available natively. Well, guess what? In addition to an array of new JavaScript APIs, HTML5 replenishes native JavaScript with classList.

The classList object provides the add, remove, contains and toggle methods to facilitate easy and quick class manipulation natively by developers. Let’s explore.


The classList object has the following properties:
   length: number, // returns a class count
   item: function(){ }, // index
   contains: function() { },
   add: function(){ },
   remove: function(){ }


The contains() method is used to check whether a class exists on the node or not. It returns a boolean value; true or false.

var myElem = document.querySelector(‘#wrapper’);
myElem.classList.contains(‘parent’);// returns true or false


The add() method, as you might have gathered, adds a class to the selected node.



Conversely, the remove() method removes the ‘passed’ class from the selected element.



Yes, you guessed it, the toggle() method adds and removes the class. So, if the class exists, it is removed, and vice versa.


This is predominately used with events such as click and hover.

Browser support

classList is well supported in modern browsers and as of this writing, according to, global browser support stands at 75.6%. If you are supporting legacy IE, be sure to use a fall back for IE9 and below.

Useful resources

HTML5 – Link and DNS prefetching

link and dns prefetching

In a world where instant gratification is paramount, it is imperative that our web applications are optimized for speed and performance. HTML5 has two features that many developers are unaware of, namely prefetch and prerender. ‘Excuse-moi?’ I hear you say. Well maybe not in French, but you know what I mean. Let me elaborate.

Link prefetching and prerendering

The prefetch HTML5 feature allows the developer to silently fetch a page or asset as soon as the page loads. This page or asset will therefore instantly load when the user makes the request via a designated link. This feature only fetches that exact specified resource (URL).

Content prefetching and prerendering can be invaluable in dramatically speeding up your website by shaving off valuable milliseconds on http latency.

This dramatically improves load speeds of your pages and is especially useful for mobile applications.

Prerender on the other hand will render the whole page in the background albeit with some limitations. Use these features sparingly however, as over use can prove counter productive (Well, like anything in life, too much of anything is…). Only prerender pages that are likely to be visited by the user. And the code? In the head section of your web page, add the following code replacing the href values with your own.

Prefetch and Prerender examples

<link rel="prerender" href="" />
<link rel="prefetch" href="" />

Adding the code above to the head section will prerender the about-me.html and prefetch my_logo.png in the background as soon as the page loads making those two items available as soon as they are requested. Since a round trip to the server is not required when the user clicks on the about me link, the page will load almost instantaneously.

DNS Fetching

In order to reach a given hostname, the browser needs to do some work to resolve the underlying domain or DNS. This has a speed overhead. DNS prefetching allows you to manually specify which domains to prefetch and here is the magic:

DNS prefetching

<link rel="dns-prefetch" href="" />
<link rel="dns-prefetch" href="//" />

In the code above we are explicitly telling the browser to resolve the two domains. This is all done in the background unobtrusively and in turn improving HTTP latency.

Google uses prefetching on its results page to provide instant pages. As soon as you enter your search query and Google is fairly certain of what you are looking for, it starts prerendering the pages using the techniques above. So when you click on any of the results, the page appears to load almost instantaneously.

Support and implementation of the above features is still in flux but, here is a simple guide to follow;


prerender – resolves DNS, loads URL, loads whole page.
DNS-prefetch – resolves DNS.


prefetch – resolves DNS, loads URL
DNS-prefetch – resolves DNS.


DNS-prefetch – resolves DNS.

If you want to prerender a page in browsers that support this feature (Chrome), and prefetch in other browsers (Firefox and IE9+), you can pass both features in the rel attribute.
  <link rel=”prefetch prerender” href=”…” />

In conclusion, patchy support should not stop you from using these and other HTML5 features in your projects, as long as you provide a fall back where possible for browsers that do not support a given feature.

Happy coding!

The HTML5 datalist element

html5 datalist

I speak for many a developer when are I say that until recently, web forms were one of the most mundane and uninspiring elements of a web page. As a matter of fact, I had disdain for creating and using web forms. But thanks to an array of HTML5 form attributes, input types and elements this is no longer the case. In this post I am going to focus on the datalist element.

The datalist element enables you as a developer to provide a predefined list of values to the user as well as allowing them to enter their own. The datalist element is used with an input element using the list attribute, to link it to the datalist. For example;
<input value=”” list=”fruits” />
<datalist id=”fruits”></datalist>

The list attribute above links the input field to the datalist via the datalist id, in this case id=”fruits”.

You can then nest options inside the datalist element. Let’s have a look at a handful of examples.


For text input fields, the datalist element allows us to set a predefined list analogous to a drop down list. The user is however not limited to the predefined list items. Unlike the drop down list, the user can still enter items not on the list, as I illustrate in the demo below.

here is the code;

<input type="text"  list="editors" />
<datalist id="editors">
  <option value="Notepad++" />
  <option value="Sublime Text" />
  <option value="Dreamweaver" />
  <option value="Coda" />
  <option value="e-texteditor" />
  <option value="Vim" />
  <option value="UltraEdit" />


Most modern browsers handle the date input field well. datalist takes it that one step further by allowing you to add suggested dates and specify labels.

<input type="date"  list="dates" />
<datalist id="dates">
  <option value="Christmas day">2013-12-25</option>
  <option value="Labour day">2013-05-01</option>
  <option value="Birthday">2013-11-26</option>


If you are not familiar with range input type, it allows the user to pick a value from a given range. You can extend this with our new found friend datalist, by setting predefined markers of values for the user to pick from.


<input type="range" value="0" min="0" max="90" list="ranges" id="range" />
<output for="range" >0</output>
<datalist id="ranges">


This is another HTML5 input field that allows the user to select a colour from a colour picker. The datalist element can be used to provide a predefined list of colours.

<input type="color" value="#000000" list="colours" />
<datalist id="colours">
  <option >#c0ffee</option>
  <option >#bada55</option>
  <option >#0ff1ce</option>
  <option >#b00b00</option>
  <option >#deface</option>


Akin to the date input field, the week input type allows the user to pick weeks rather than days. With the help of datalist, we can again give the user a list of weeks to pick from.

<input type="week" list="weeks" />
<datalist id="weeks">
  <option label="14th Week of 2013" >2013-W14</option>
  <option label="15th Week of 2013" >2013-W15</option>
  <option label="25th Week of 2013" >2013-W25</option>
  <option label="52nd Week of 2013" >2013-W52</option>
  <option label="30th Week of 2013" >2013-W30</option>


I hope that gives you an insight in the datalist element. There are more input field types that can be linked to datalist element. I have only scratched the surface above to demonstrate its use.

Unfortunately, support for input types introduced in HTML5 is sparse, especially by Internet Explorer, where even IE10 has only implemented a handful of them. Since the datalist element is inextricably linked to input fields, you will find usage is currently limited. This however doesn’t mean you shouldn’t use these new funky elements as long as you have provisions (gracefully degrade) for unsupported browsers.

Useful resources

HTML5 Geolocation API – The basics

html5 geolocation api

Location, location, location. No, I am not writing about real estate but rather a new HTML5 API that empowers developers by giving them the ability to get the geographical location of a user. In this post, I will cover the basics of the API – mainly how to get started – and I have also put together a demo to boot. The demo shows your approximate current location.

Geolocation makes the user’s location co-ordinates available to JavaScript which can then send them back to the server. This information can then be used by the developer to personalize user experience and tailor content for the end user based on location. Many retail sites, for example, tap into the geolocation API in conjunction with the Google maps API to show the user a nearby store.

Note: The browser or device must get express permission from the user before disclosing their location.

All modern user agents, otherwise known as browsers, have implemented the API, albeit the implementation is still in flux. The browser or device must get express permission from the user before sending their location co-ordinates, which comes as a relief to many users who would rather not share their location with a web site or application.

Get current position

In its simplest form, the geolocation function is;
function getLocation(){

Unfortunately, since the API is not implemented across all browsers at the time of this writing, we have to make provisions for antiquated browsers. This is where a really handy feature detection library called Modernizr (If you are not using it, you should) comes to the rescue. We can use Modernizr to test for geolocation support, providing a fall back where the API is not supported. Let’s rewrite the above code;
function getLocation(){
    //no support, provide a fallback. Maybe


What happens behind the scenes

Remember for the browser to send the user’s location, the user must grant permission. So when you call getCurrentPosition() method the following happens;

  • The user will get a prompt alerting the user of the fact that the website wants to know their location
  • The prompt will request the user’s consent to share their location
  • The method is ‘blocking’ so the website cannot bypass it

Below is an example of a prompt you get in Chrome;

Getting the user’s co-ordinates

If the user consents to sharing their location, the callback (I have called mine showMap) will fire. The callback takes one argument which is an object that contains both the coordinates and a timestamp. Let’s write the showMap function;
function showMap(position){
  var latitude = position.coords.latitude;
  var longitude = position.coords.longitude;
//we can place the map on the canvas

The position object passed as a parameter in the showMap function consists of the following properties;

  • coords.latitude – degrees
  • coords.longitude – degrees
  • coords.altitude – meters
  • coords.accuracy – meters
  • coords.altitudeAccuracy – meters
  • coords.heading – degrees clockwise
  • coords.speed – meters per second
  • timestamp – similar to the Date() object

Now, working on the premise that geolocation works on a opt-in basis, we have to be prepared for some error-handling in the event that the users decides not to share their location. The second argument to our getCurrentPosition() method, is the error handling callback. So let’s update our function to that effect.
navigator.geolocation.getCurrentPosition(showMap, errHandler)

If there is a problem, the errHandler() callback will fire. The error handler has a PositionError object which is one of the following;

  • PERMISSION_DENIED(1) – The user has denied you access to their location
  • POSITION_UNAVAILABLE(2) – The network is down
  • TIMEOUT(3) – It took too long to calculate the user’s position

Above codes in hand, we can handle all three cases as we see fit. For example, if the user opts not to share their location, our error handler would be something like;
function errHandler(err){
  if(err.code == 1){
    //user said nada

The getCurrentPosition function takes a third optional argument called PositionOptions. This is an object with three properties namely; enableHighAccuracy, timeout and maximumAge. As you can deduce from their names, enableHighAccuracy provides as an accurate a result as possible. If set to true, this might however result in a slower response. Timeout is the number of milliseconds your application is willing to wait for a calculation, and maximumAge allows the application to use a cached position within a specified time frame. I illustrate one of the three optional properties below;
navigator.geolocation.getCurrentPosition(showMap, errHandler, {maximumAge:85000})

Cross browser support

Most modern browsers including IE9 and above support geolocation natively. However, if you are still supporting legacy IE (IE8 and below) do not despair. Help is at hand in the form of geoposition.js.


Geoposition.js is a geolocation polyfill that not only simulates the functionality in legacy IE, it also standardizes implementation across the numerous platforms, mobile included. To use the library, simply download the script from github and call it from within your document. Remember it is a best practise to add your scripts at the bottom of the body section even though technically, you should add them to the head section. While scripts are loading, they will stop the rest of the page from loading (also referred to as blocking). By adding them to the bottom of the page, you avoid this.

non-blocking geoposition script tag

<!doctype html>

  <script src="js/geoPosition.js"></script>

Once you have the script in place, you are now ready to use geolocation with assurances that it will work cross browser and cross platform.


To initialize geolocation, do the following;
  geoPosition.getCurrentPosition(successCallback, errCallback, {enableHighAccuracy:true})
  //geolocation is not available on this device or browser

We can now write the succesCallback and errCallback functions.

Success callback

function successCallback(p){
  //p : the the geolocation object as the passed argument
  //p.latitude : the latitude value
  //p.longitude : the longitude value value

Error callback

function errCallback(p){
  //p.message : the error message

The API is well documented on github, so if you are interested in all the bells and whistles, read the documentation.


To quickly demonstrate geolocation, if the user’s browser or device supports geolocation, I have added a simple link to this page and attached a click event listener. When the user clicks the link, the geolocation function is called and the magic happens. Otherwise, I simply display a “your browser doesn’t support geolocation” message. GIVE IT TRY!

Note: Remember to drop in at the google developers page to grab an API key which you will need use google maps in your projects.

That’s it people.

Useful resources

What’s new in jQuery 1.9


The latest major iteration of jQuery was released on January 15, 2013. But before you run off to update your applications with jQuery 1.9, be sure to read the rest of this article. JQuery 1.9 is a major milestone in the library’s evolution as it:

  • removes some of the deprecated features, leaving a slimmer library (90.4kb)
  • is the last major version to support IE6,7 and 8.

The removal of some of the most used but now deprecated features from the library, means that not many sites will go unaffected by simply swapping old for new as jQuery 1.9 is not backward compatible. You should not despair however as three jQuery enthusiasts have written jQuery migrate plugin which detects and re-enables deprecated features found in existing code. These are logged in the developer console making it easy for the developer to fix the issues. The plugin is very well documented and hosted on github.

Caveat: Make sure you load the plugin immediately after jQuery 1.9 as demonstrated below.

jQuery migrate plugin

  <script src="" ></script>
  <script src="" ></script>

Quick tip: To quickly test how your site handles the update, you can use a debugging proxy tool such as fiddler to swap out your current jQuery version for 1.9. This allows you to test locally without affecting any of your user’s experience.

The plugin will also work when upgrading to jQuery 2.0 which among other things, will be abandoning legacy IE. Is dropping support for IE6,7,8 premature? That’s a question that I am sure divides opinion but one that I am not going to address in this article.

Features removed

  • die() – use off() instead
  • andSelf() – use addBack() instead
  • live() – use on() instead
  • The “hover” pseudo event is no longer supported as a synonym for “mouseenter mouseleave”
  • $.browser() – removed

The above list is not definitive but those are the most commonly used features that are bound to be flagged up in most code.

New features

.css() multiple property getter

You can now pass an array of css properties to the .css() method. This will return an object of the property values passed e.g:

.css() Multiple property getter

  var elDims = $('elm').css(['width','height','backgroundColor']);
  //{ width:"50px", height:"50px", backgroundColor:"#c0ffee" } 

.finish() method

Until now queued animations have been handled by the .stop() and .clearQueue() methods. .finish() is the new way to stop animations and place them in their final state

CSS3 selector support

The following CSS3 selectors are now supported in all browsers:

  • :first-of-type
  • :last-of-type
  • :nth-last-child
  • :nth-last-of-type
  • :nth-of-type
  • :only-of-type
  • :target
  • :root

prop() vs attr()

jQuery 1.9 encourages the use the right method for the occasion. In most cases where attr() is used, prop() is probably the right method to use albeit attr() working. However, the method you use should always be determined by what you are trying to retrieve or achieve. There is a very good discussion thread on stackoverflow that explains the difference.

Source maps support

jQuery 1.9 adds the ability to map minified versions of code to the un-minified versions making debugging easier.

This is a welcome addition as often times the errors are tacked away in some minified code. It also means that we can minify our code before deployment which will improve performance.

I am not going to go into details about source maps in this article but their is a very good article titled The Magic of the jQuery 1.9 Source Map
by Elijah Manor that goes into details on how to set up this feature

Ajax events

Ajax events must now be attached to the document not the DOM node when using the ajaxStart() method. i.e $(document).ajaxStart(…); and not $(‘#node’).ajaxStart(…);

The ajaxStart() method specifies what function to run when the AJAX request starts. For example, let’s say you had a button on a page that loads some content asynchronously e.g. $(‘button’).on(‘click’, function(){ $(‘#elem’).load(‘some_page.html’) })
You can show a pre-loader (animated gif) while the content loads by using the ajaxStart()method. Something like; $(‘#elem’).ajaxStart(function(){ $(this).html(‘<img src=”preloader.gif”/>’); })
This will show a animated gif as soon as the request is made, which in turn is replaced by the content once a response is complete.

To upgrade or not to upgrade

As is the case for any new library, it’s advisable to wait for some time before you install, or upgrade to the new iteration. I’d suggest you wait for a few more weeks while all the issues that may arise are ironed out.

Unlike it’s predecessors, jQuery 1.9 will not be a straightforward plug and play upgrade because of the aforementioned changes, but the jQuery migrate plugin provides a bridge that will make the process less painful. jQuery is evolving, and soon or later we must/will embrace the change.

In closing…

jQuery 1.9 lays the foundation for the big one, jQuery 2.0 which drops support for IE6, 7 and 8. Now, IE8 is the highest version that you can run on windows XP and there is still a high percentage of windows XP users who see no reason to upgrade to windows 7. This means that developers will continue to support IE8 for a while yet.

Here is a dilemma that is going to face developers; should we have two jQuery code bases for our applications, conditionally loading a jQuery version depending on which OS the user is running? Or are we going to stick to jQuery 1.9 foregoing all the added features in jQuery 2.0? There is a conundrum for you to ponder.

Useful resources

Writing Modular JavaScript


I will start off by saying that I am no guru when it comes to JavaScript. There are guys who will have me for breakfast when it comes to this stuff, as they were in this business way before I knew what a span was. That said, I am starting to get cosy enough with JavaScript to a point where I feel that I can share some of what I have learnt over the past few years. This article is geared towards intermediate JavaScript developers who aspire to becoming better developers. In my quest to becoming a decent developer, I scoured the web for good resources and I feel that it is only right that I give back.

Programmers with a background in languages such as Java and C++ dislike JavaScript because it does not have structure and well, it is a ‘weakly typed’ (= no type declarations) programming language. What the detractors don’t or refuse to see however, is that; because JavaScript does not force a structure on you, this allows expressiveness and imagination. That said, this freedom is often abused by developers who write unreadable and unmaintainable code. To combat this, we can approach coding in a more pragmatic way, by writing our code in a Modular fashion and adopting proven coding techniques, better known as design patterns.

Design patterns are proven coding techniques that make code readable, scalable and maintainable.

There is a plethora of material on design patterns and I give a few links to my favourites in the “useful resources” section below.

Modular code is a term that is now prevalent in the JavaScript echelon which simply means; writing your code in sections that are readable, scalable and maintainable. We have all written ‘spaghetti’ code due to time constraints or just out of sheer ignorance (we didn’t know any better). Usually within a few months we can hardly discern our own code, not to mention the mess we leave for people who inherit our code.

Writing Modular JavaScript gives structure to your code, and helps in limiting the number of global variables, which in turn improves the overall performance of your application/website. I particularly like the object design pattern when writing Modular code as it makes reading and maintaining code such a breeze. Well, I think it’s time to get down to the nitty gritty of Modular JavaScript.

Task at hand

To demonstrate the concept, let’s set up a module for a twitter widget that displays the latest tweets from a twitter account on a website. It displays the first 6 tweets and offers a ability to load more tweets by way of a button.

Our Module

Let us simply call our module TweetsWidget. Normally, I would use the camel case naming convention for my variables but I will capitalise module names as it makes them stand out.

Module definition

	var TweetsWidget = {}


To make our widget configurable and give the users more leverage we will provide some settings that can be changed to suit the users needs. Our widget module will have methods that perform different tasks. Since these methods might need access to the configurations, we will create a variable c which points to the configuration settings.


var c,
    TweetsWidget = {
		tweetCount: 6,
		tweetsWrapper = $('#our-tweets'),
		moreTweetsBtn = $('#tweets-btn')

	| innitialise
	init: function(){
		c = this.settings;

Binding widget events

Since we are adding a button for users to load more tweets if they so wish, let’s create a method that handles the UI events of our widget. Some developers may view this as unnecessary, but I think it makes our code more structured and readable. This will invoke the method that actually does the work. i.e loads more tweets.


var c,
    TweetsWidget = {
		tweetCount: 6,
		tweetsWrapper = $('#our-tweets'),
		moreTweetsBtn = $('#tweets-btn')

	| innitialise
	init: function(){
		c = this.settings;

	| click handler
	evntHandler: function(){
		c.moreTweetsBtn.on('click', function(){

	| utility that loads more tweets
	getMoreTweets: function(num){
		//we use num as a parameter for the number of tweets we want
		//we probably use some AJAX here to avoid entire page reloads.

We will not write the getMoreTweets method as this is only a demonstration of how to structure our code. That’s it! We now have a module whose job is to handle the loading and displaying of recent tweets onto our site. It is evident that there is no ambiguity as to what the code does, it’s readable and maintainable. If we decide to augment our module, all we have to do is add another property to TweetsWidget and invoke the method via the init function.

What next?

We can now use another script, whose job is to load modules, to call the TweetsWidget module. This script will probably be used as a module loader as it is very likely that we will have more JavaScript on our site.

Module loader

	//load tweets widget

	//load some other module


This is perfect on small projects. On big projects however, the number of modules can quickly get out of hand which could lead to big performance overheads and slow page load times due to the number of files being loaded. Also, you might not necessarily want some of the modules loaded into every page on your site.

To combat this, we can use a Asynchronous Module Definition loader (AMD). RequireJS is a very popular script that handles module loading very well. I am not going to go into details about AMD or RequireJS as they both deserve their own forum. I will nonetheless encourage you to check out the ‘useful resources’ section below.


The benefits of writing Modular JavaScript are clear for all to see. Some people might argue that loading several JavaScript files increases page load times. I would say that this is becoming less of a problem with modern browsers that have faster rendering and JavaScript engines. Another solution to the problem is to load your files asynchronously using tools such as RequireJS. Among other useful features that RequireJS brings to the table, is a build tool that amalgamates all your files and minifies them before serving them to the browser.

Writing JavaScript in a Modular fashion will also go a long way in nullifying the perception that JavaScript is messy, unreadable and unmanageable. If we all as developers get onto the Modular JavaScript bandwagon, then maybe, just maybe, all the naysayers might come along for the ride.

Useful resources

Do more with LESS


If you are like me, you have probably wondered why hitherto in CSS, we have not been able to use variables, functions and other general programming good practices given its verbose nature. Most developers that write CSS are familiar with programming principles and wouldn’t it be great if these could be applied to CSS? Well, we are in luck, say hello to LESS.

What is LESS?

LESS is a syntax or preprocessor that takes CSS and applies familiar programming principles such as variables, functions, mixins (more about this little number later) and nesting. What we get, is a smarter and dynamic language for writing CSS. You can take either the client-side or server-side approach when implementing LESS. When using the client-side approach, LESS is interpreted into regular CSS by way of JavaScript at runtime.

The ability to declare variables for example, gives us a more efficient way of changing values after the fact. For instance, if we decide that we now want to change a color used on the site from cyan to hot pink, we do not have to scour the stylesheet for all the instances of cyan. All we need to do is change it at source i.e where the variable is declared. LESS also brings the benefits of utility functions to CSS, a much welcome addition. LESS derives its name from yes, you guessed it; the ability to write less CSS.

How easy is it to get the ball rolling?

Compared to the other preprocessors, compass/SASS and Stylus, both of which need Ruby installed on your machine, LESS is child’s play so to speak, when it comes to implementation for client-side usage. It takes nothing but a couple of steps to get up and running.

Step 1
Create a .less file and link to it from the head section like so: <link type=”text/css” rel=”stylesheet/less” href=”main.less” />

Step 2
For client-side usage, head off to, download less.js and reference it from the head section.
<script src=”js/less.js”></script>

Important: It’s imperative that the stylesheet reference is placed above the Javascript script tag.

And that’s it. You are now ready to start writing LESS.

If you are however looking for some flexibility, you can configure certain aspects and functionality on the LESS global object. You can find out more about configuration in the documentation.

For the server-side approach, it is highly recommended that you use npm. Node.js (a server-side JavaScript interpreter) provides a package manager(npm) that runs through the command-line tool. This is the best way to install and use LESS server-side. I am not going to get into details on the command-line approach, but if you are interested, there is a very good wiki on the subject on github.

Now the syntax

The LESS syntax/language is very similar to CSS. All LESS and other preprocessors do is add cool features to CSS. By way of example, I will demonstrate some of these features.


LESS variables are prefixed with a @ sign and once declared can be referenced throughout the stylesheet. We can use variables for any CSS values e.g colors, text or numbers. This is an efficient way of storing values as we only have to change them in one place as opposed to regular CSS where one has to scan through the stylesheet for all instances of the value in question.


      border:1px @borderStyle @borderColor; 

here is the CSS after compilation:


      border:1px dashed #f0f;

So, if we decide to change #c0ffee to #bada55, we only have to change the value of @bgColor(declaration) and all the instances of @bgColor within the stylesheet will be dynamically updated.


Mixins are akin to functions in that they are blocks of code that can be invoked anywhere within the stylesheet. They can accept arguments similar to functions in other programming languages – say, JavaScript. A very good use case scenario is vendor prefixes. In many cases we find ourselves repeating vendor prefixes for features that are not yet supported in some browsers.

Using a mixin can make this more dynamic and efficient as I demonstrate below.


div { .border-radius(10px); }

Now whenever we want to add rounded corners to an element, we just call our new border radius mixin and pass in a value. Here is the *compiled CSS;



Imagine what we can do with this feature! For instance you could create a mixin with default values or pass your desired value at invocation. Here is another example;
//create a mixin that accepts an optional background color
.flag(@bgColor:”#cf0″){ background-color:@bgColor }
//apply styles from the mixin above
.highlight { .flag(); border:1px solid red; }
//or pass in a different color
.highlight2 { .flag(‘#333’); }

Color functions

Color functions are some of the built-in functions that come with LESS. They give us the ability to create variations of a single color. A good use case scenario is when you want to create gradients or hover colors. In the snippet below, I dynamically generate a link hover color using the darker color function;

LESS color function

a { color:@color; }
a:hover { color:darken($color, 25%); //the hover link will compile to 25% darker than @color } 

Other color functions include;

  • lighten – lightens @color by a specified percentage
  • saturate – compiles to a more saturated color
  • desaturate – does the opposite of saturate
  • mix – returns a mix of two colors

LESS has many more built functions that can do much more. Refer to the LESS documentation for more.


If you are familiar with the CSS cascading principle, you will know that it leads to a lot of repetition. Say for example;
#main { color:#f0f; }
#main .first { color:#c0ffee; }
#main a { text-decoration:none; }
#main a:hover { tex-decoration:underline; }

LESS alleviates this repetitiveness by introducing nesting. We can re-write the above code as follows;

Nesting in LESS

#main { 

    &:hover{ text-decoration:underline; }

Note the use of the ampasand(&) for pseudo classes. The same applies for element type selectors e.g p.warning


Yes, you read right. In LESS you can perform operations on variables and color values. Lets do some simple operations in LESS;

LESS Operations

@width: 150px;
@height: 50px;
div { 
  width:(@width + 5); //this will evaluate to 155px   
  height:(@height * 2); //this will evaluate to 100px


LESS is picking up traction in the web development community primarily because, by adding useful features such as variables and functions, LESS saves time. Try it in your next project and you will not be disappointed. As I mentioned earlier, Compass/SASS and Stylus are the other CSS preprocessors at our disposal but I think LESS is by the far the easiest to work with.

A word of caution: Compiling client-side has a performance overhead, especially on big projects. It’s recommended that you either use caching on compile server-side.

Note: I should point out that I have used the term ‘compile’ loosely for emphasis. Strictly speaking JavaScript does not compile, it interprets.

Useful resources

Saving form data using the localStorage API

HTML5 local storage

Here is a scenario that we can all relate to; You are filling in a long form and half way through, you inadvertently close the tab/window or worse still your laptop decides to crash. ‘Argh!, I was half way through that form, now I have to start again?’ comes to mind. Well, fret no more. Thanks to the localStorage API we can store form values (and more) on the fly so that in the event that the above happens, the values already entered will still be in browser memory. Storing persisting data has never been easier, and it lends itself well to enhancing user experience. I can here you say, but isn’t that a cookie? No way Jose! Sit back, relax and enjoy the ride!

What is this localStorage API thingy?

Simply put, localStorage is a JS API (commonly referred to as part of the HTML5 spec) that facilitates data storage in the browser. This is in form of key/value pairs that persist even when the user navigates away from the page. Persistence is where the similarity between localStorage and cookies ends. Not to be presumptuous, key – A name for a value to be stored. value – The value stored. Unlike Cookies,

  • localStorage does not expire, Cookies do
  • the localStorage API recommends up to 5MB, Cookies are small(approx. 4kb)
  • The localStorage API is very easy to work with as it’s simply a JavaScript object made up of key/value pairs, Cookies are messy NOTE: even if an object, the localStorage object can only store simple data types i.e strings, numbers and floating points.
  • localStorage is not sent in HTTP requests, Cookies are. This adds an overhead to your web application as unnecessary requests are made to the server.

localStorage can be accessed via the global window object and is supported in the latest iterations of all the major browsers, IE included. As a matter of fact localStorage is supported as of IE8. To test for localStorage support, simply let Modernizr (you should be using it) do the detection for you, here is how;
   //browser supports localStorage
   //browser does NOT support localStorage

You however do not have to use Modernizr to test for localStorage support. You can simply check if the window object has the localStorage property;
   //browser supports localStorage
   //browser does NOT support localStorage

but then again, Modernizr aids the detection of all the other cool progressive enhancement features, so why not take advantage.
Crash course over!

So how do I use this nice API to save form data?

As I alluded to above, the localStorage API makes working with persistent data a breeze. It’s also very easy to implement. So without further ado, here we go;

localStorage implementation

    //browser supports localstorage

    	//lets store input field data in a field on blur.
    	$('form').on('blur', 'input', function(){
    		//set a flag to indicate that we have saved data! 

    		//lets serialize the form data using jQuery's serializeArray()
    		var data = $('form').serializeArray();

    		//lets loop through the data and save the input data 
    		$.each(data, function(i, obj){
    			localStorage.setItem(, obj.value);

    	| if saved form data exists set input field values. 
    	| Note: this will naturally run before the above code 
    	| which is only triggered on the blur event.
    	if (localStorage.getItem('flag')){
    		var data = $('form').serializeArray();

    		$.each(data, function(i, obj){


   //NO native localStorage support - resort to a fallback eg $.localStorage()


In the above snippet, we test for localStorage support which if successful, and after the DOM is ready, we use the blur event to trigger localStorage, calling the setItem() method in particular. This little number will create key (, value (obj.value) pairs for all input fields other than the submit button and store these as an array of objects stored in browser memory. We do this by iterating through the serialized form data. In layman talk, every time the user moves away from a field we tell the browser to store the values in the input fields.

Great! We have now stored the data, but how do we then retrieve this data? Before we retrieve the data and populate the respective fields, note that we set a flag if localStorage.setItem() has been invoked on the form data. We can then maybe alert the user that form data was saved last time they filled in the form, but we can also use this flag as a test for presence of saved data. We then serialize the form data so that we can loop through it and set the values of the input fields. Note that instead of invoking the setItem() method, we are now calling upon its sibling getItem().VoilĂ ! Easy as pie.

Being the nice developers that we are, we can also provide a way for the user to clear the form fields if they so wish, by simply adding a button to clear input data. The click event handler for the button will be something akin to;

$(‘#clear-btn’).on(‘click’, function(){ localStorage.setItem(‘flag’,”) })

On clicking the ‘clear button’ the value of the flag will be set to empty string which is a falsey value. Consequently, when the user reloads the page, the code that sets the input values to the stored data will not execute/run.

Browser support


The fact that the localStorage interface is a lot easier to use compared to the now ageing cookies, is the reason this API has had rapid adoption by many in the development community. There are many applications for localStorage but I have used persisting form data as a way of whetting your appetite and I implore you to explore this cool API further. Hopefully, this will make storing and working with client-side data a tad bit easier.

That said, localStorage should be used judiciously and users should always be made aware that their data is being stored albeit to improve user experience. Don’t forget those disclaimers!

Useful resources

PictureFill – A responsive images technique

Responsive Images

If your web application takes more than 3 seconds to load, you will soon get a call from the the latency police to explain yourself. Users expect snappy applications otherwise they will move on to the next website with better user experience. For businesses, you can not overstate the importance of fast applications as this could be the difference between success and failure. One of the reasons most web pages take a long time to load is the amount of requests made by the browser and the size of the files that need to be pre-loaded. Reducing the amount of requests, is at the core of improving user experience.

Recently in my day job, I was assigned a task of creating a prototype to demonstrate responsive images. Fishing rod in hand I headed off fishing for some new techniques. There is no shortage of server and client side techniques but I settled for PictureFill.

What is PictureFill?

PictureFill is a responsive image technique devised by Scott Jehl that makes use of the proposed picture element and media queries to serve images based on browser window size.

How does it work?

An img element is created on the fly using JavaScript based on the source and media query specified within the picture element. This prevents unnecessary overheads that are otherwise incurred by pre-loading large files, especially on small or low speed devices.

Implementation – Some code please!

Head off to the Github code repository and download the code files. The code is very well documented and includes examples. I will nonetheless give a quick run down on the html markup.

PictureFill HTML markup

<picture data-picture data-alt="big pebbles">
  <source data-src="img/pebbles_small.jpg">
  <source data-src="img/pebbles_medium.jpg" data-media="(min-width: 400px)">
  <source data-src="img/pebbles_large.jpg" data-media="(min-width: 800px)">
  <source data-src="img/pebbles_extralarge.jpg" data-media="(min-width: 1000px)">

  <!-- Fallback if no JS -->
      <img src="img/small.jpg" alt="big pebbles">

In the snippet above, I use the picture element to nest all the various image sources using, well the source element. Note that I also specify the screen resolutions using media queries passed as values for the data-media attribute. The beauty here is the ability to cater for as many screen resolutions as you want.

For users with JavaScript disabled, we have a fallback image which is wrapped in noscript tags. This piece of code will not be executed by browsers running JavaScript.

Well as usually, IE demands special treatment. Using IE conditional comments we can provide a one-size-for-all image for IE8 and below as Media Queries are not supported here. For example if I wanted to serve the medium image to IE8 and below, I can nest the following inside the picture element:
<!–[if (lt IE 9) & (!IEMobile)]>
  <source data-src=”img/thumbs/pebbles_medium_thumb.jpg”></div>

If you are understandably apprehensive about using the picture element as it’s still in draft status with the w3c, you can replace the picture and source tags with the div element. Remember however to make the switch in the JavaScript as well i.e replace all the picture instances with div. My take on standards is that; they do not really mean that much if the browsers do not implement the module in question. After all users are not concerned about whether the your code is legal or not. That’s not to say that we should totally disregard semantics and standards. Word is that a few browsers have began implementing the picture/source model.


To many this might seem a very involved workaround to a problem that does not yet have a standardized solution, but until a fix comes along, this is a semantic workaround for the purist. As I mentioned earlier, there is no shortage of polyfills and workarounds in the web dev community, but this by far gets my vote.

Useful resources

  • Adaptive Images – a server side responsive images technique
  • HiSRC – a jQuery plugin for responsive images
  • Senchia.IO – cloud based service for mobile development.

Chrome Frame turbo charges Internet Explorer

Media Queries

Internet Explorer (IE) has a rather unfashionable habit of showing up to the CSS3 and HTML5 party late. Someone ought to tell Microsoft that their browser has caused many a heartache and angst amongst designers and developers who strive for equal user experience for all mankind irrespective of their browser of choice. Rant over!

Let us focus on people that are opting into the future and are ready to embrace new web technologies, moreover Chrome Frame has now been stable since 2010. In an effort to solve the aforementioned annoyance, a few people at Google got together and came up with a rather canny solution; wrap IE in Chrome’s clothing. And Chrome Frame was born.

What is Chrome Frame and why?

Chrome Frame (GCF) is a plug-in that brings new web technologies to IE. As of writing, technologies such as websockets, and canvas are not supported in IE8 and below. Chrome Frame alleviates this problem. GCF not only brings with it all the good CSS3 and HTML5 features that are otherwise not yet supported by Internet Explorer, it brings Chromes’ JavaScript V8 rendering engine which provides better performance, at least in IE8 and below.

This means developers and designers can invest the time otherwise spent fixing and adapting web apps to IE or worse still curtailing functionality and UX for IE users, to developing rich applications.

Chrome Frame is also a saving grace for users that are forevermore doomed to legacy IE because their machines are not running the Windows7 OS and consequently cannot upgrade to IE9+

Tapping into Chrome Frame

Simply adding the http-equiv meta tag in the head section of your document, activates Chrome Frame in IE if the plug in is installed. Browsers that do not understand this tag will simply ignore it. The tag is as follows:
<meta http-equiv=”X-UA-Compatible” content=”IE=edge,chrome=1″>
The part to pay attention to is the content attribute. IE=edge will coerce the browser to the latest rendering mode installed if the user or browser inadvertently switches to a older version. chrome=1 as you might gather enables Chrome Frame. You can also load Chrome Frame conditionally. Say you only want to activate it for users in IE7 and below, you would add chrome=IE7 in place of chrome=1.

What if the user does not have Chrome Frame installed?

Well, the user can either do a manual install by simply visiting or as I demonstrate further below we can add a script that will prompt the user to install the plug in if it is not present.

The beauty of Chrome Frame is that the user does not need administrative rights to install the plugin. Simply append ?user=true to and you are off and running.

Implementing the detection script

In addition to the http-equiv meta tag discussed above, we can add the following script at the bottom (or head section) of our page:

Chrome Frame detection

<!--[if lt IE 9 ]>
    <script src="//"></script>

The snippet above is a Chrome Frame detection and install script that will run if the user is viewing your site in IE8 or below. A gentle prompt in form of an overlay page (not a popup) will be displayed to the user. It is really that simple. Note that the CFInstall.check() method is at the heart of this script and takes several properties e.g,

  • cssText: This is optional and allows you to style the prompt iFrame with your custom styles
  • onmissing: You can specify a custom callback function if GCF is missing

For a definitive list, visit the Chrome Frame developer guide.

To DEMONSTRATE, I have put together a simple canvas page and if you run it in IE8 or below and have Chrome Frame installed, you will see my Picaso-esque canvas drawing. Conversely, if you do not have Chrome Frame installed, you will not see that beauty. You will however be presented with an in-line dialog (not the obtrusive popup) to install Chrome Frame. Canvas is just one feature that IE8 and its older siblings do not support, there are many more where that came from.


Many big corporations and organisations are very reluctant to update to newer browsers citing financial implications to their IT departments and security risks associated with new software that has not been fully tested. These are all plausible reasons but they also hinder advancement in web technology.

Google Chrome Frame is an alternative and is a testament to Google’s enthusiasm and desire to move the web forward. Because IE has a big piece of the user pie but painfully slow at implementing the new web technologies, it cannot be taken lightly and efforts have to be made to drag it along into the future. For users who have made the wise move away from using IE as their primary browser, but have IE dependent applications, there are solutions such as IE-tab that emulate IE in other browsers.

Useful resources