I’m young and haven’t been doing this programming thing for very long so the fact that I’ve never had to use a switch-case statement (to my recollection) might not be very impressive; actually you probably see this as a bad thing and you might even be wondering why I haven’t. I can’t really explain why but I seem to have an inherent dislike of things like this:

switch (something) {
 
    case 1:
        doX();
    break;
 
    case 2:
        doY();
    break;
 
    case 3:
        doN();
    break;
 
    // And so on...
 
}

The fictional author of this code obviously doesn’t know enough about JavaScript to make use of its various other constructs, most of them ten times more suited to this situation than an ugly switch statement. It’s not its appearance that truly annoys me though; it’s the knowledge that there are so many easier and more graceful ways of achieving such functionality.

Switch statements are considered as useful when you have a single variable and dependent on its value you want to carry out one of a number of different tasks. Using multiple if-else clauses doesn’t seem appropriate so the switch statement is often called upon to lend a hand. I’m sure most of you are familier with it and have seen it more than once before.

Let’s take the example from above; dependent on the value of something we run doX, doY or doN. In JavaScript, the same logic can be expressed with a simple lookup table in the form of an object:

var cases = {
    1: doX,
    2: doY,
    3: doN
};
if (cases[something]) {
    cases[something]();
}

Not only is this cleaner but it’s also reusable, modifiable and accessible… All the conditions are saved as part of an object, so if you ever need to recall or change those conditions then it’s as easy as cases[condition].

I suspect this covers about 90% of situations where a switch-statement is used; the remaining 10% are probably legitimate uses. Using a lookup table as an alternative to the Switch statement is not new; in fact this is the only way such logic can be expressed in both the Python and Lua languages, both of which have no support for switch statements.

So, my message is the following: do not use switch-case constructs unless absolutely necessary. Why? - Because there are better alternatives; simple as that!

Read more about the “Switch Statement” here: en.wikipedia.org/wiki/Switch_statement.

I think very little about topics of this genre because I’m normally left depressed and far from reality; I rather put thinking time into modern distractions like media, the internet and other trivial pursuits. But sometimes, you’re forced into a mental corner and it makes you wonder about things far from life, like life itself and the point in you existing.

I won’t bore you with realisations you’ve probably made before; I’m sure my thoughts have been thought a thousand times before and that almost makes this tiny endeavor entirely pointless. I won’t stop though, because I think this website deserves a bit of character; I rather be more than just a code-monger; I rather be a human in your eyes.

I guess that’s the thing about the internet; it reduces a persons effort and character to nothing more than a few words on a page. It’s a reductive medium; like the TV, or radio, or a written publication. As a reader, viewer or listener you’re never going to be able to fully appreciate the emotions behind the medium. Because of this, everything is constantly belittled!

What you may not realise when using these mediums is how just one sign of gratitude can make an entire endeavor worth the effort… And I’m not talking about me or anything related to me; I’m talking about everything and everyone! Even the most altruistic people on earth would not deny gratitude; in a way, it makes their actions all the more significant. It’s not the words themselves that are important; it’s the fact someone has said them!

Other times, the words mean nothing, because we hear them so often. When you read a paper I bet you rarely really think about what you’re reading; oh, another bomb killing 50 people, another dead celebrity, another abused child dead… These headlines come easy off my tongue because I hear them so often; they’ve lost all meaning. Do you feel pain when you hear that 200 people have died, regardless of cause? Does it mean anything to you, or is it yet another headline describing the unfortunate fate of someone you’ve never met?

Look at the following code:

$( '#something' ).width( this.parent().innerWidth() ); /* NOT POSSIBLE */

This is what I’d really love to be able to do ($('#something') is assigned to this in the background). But, unfortunately, there’s no way to change the value of this (because it’s immutable); plus jQuery provides us with no way to grapple the previous selection. So, unless I want to mess around with functions as setters there’s really only two ways of doing what I want:

// #1 (BAD PRACTICE - selecting twice)
$( '#something' ).width( $('#something').parent().innerWidth() );
 
// #2
var something = $('#something');
something.width( something.parent().innerWidth() );

So now we’re left with only one acceptable way of doing this; assigning $('#something') to a variable and then referencing that variable from that point onwards.

I accept that this is the “best practice” but, to be honest, I really hate it… Just looking at it; it seems unnecessary. And I don’t want to mess around with functions as setters because that just makes the code even more bloated. Instead, I’d much rather have a property under the jQuery namespace that will always be referencing the last selection. Something like this:

$( '#something' ).width( $._this.parent().innerWidth() );
/* $('#something') === $._this */

And as the code progresses, $._this is re-assigned continually; always reflecting the previous selection.

Maybe, in the future, the jQuery team will choose to implement something like this, but, for now, it’s possible using the following “hack”:

(function(_jQueryInit){
 
    jQuery.fn.init = function(selector, context) {
        return (jQuery._this = new _jQueryInit(selector, context));
    };
 
})(jQuery.fn.init);

NOTE: This is not the same as jQuery(something).prevObject.

I know its usefulness may not be immediately apparent to all of you; and I don’t blame you if you don’t find this technique appealing, but, before you make your decision, consider that its usage is quite specific and I think you’ll only really understand its appeal when you’ve encountered a situation that requires it.

• The string to be wrapped.
• The column width (a number, default: 75)
• The character(s) to be inserted at every break. (default: ‘\n’)
• The cut: a Boolean value (false by default). See PHP docs for more info.

The code

function wordwrap( str, width, brk, cut ) {
 
    brk = brk || '\n';
    width = width || 75;
    cut = cut || false;
 
    if (!str) { return str; }
 
    var regex = '.{1,' +width+ '}(\\s|$)' + (cut ? '|.{' +width+ '}|.+$' : '|\\S+?(\\s|$)');
 
    return str.match( RegExp(regex, 'g') ).join( brk );
 
}

Usage

wordwrap('The quick brown fox jumped over the lazy dog.', 20, '<br/>\n');

The quick brown fox <br/>
jumped over the lazy <br/>
dog.

I know there are other solutions out there; the ones I saw seemed a bit slow though, not to mention unnecessarily complicated/bloated…

The jQuery plugin I mentioned attempts to use watch() if it’s available, otherwise it uses setInterval, repeatadly iterating through a stack of objects checking for changes. Even this attempt at a unified solution is futile because the functionality behind watch() is fundamentally unachievable with cross-browser JavaScript. According to this MDC documentation, the watch method not only acts as a type of event registrar for property-changes but also has the capability to define the property’s value (following the attempted change). In other words, the psuedo-event from watch() will fire before the property is actually changed, not after - the return value from the handler becomes the actual value of that property. Therefore, any attempts at emulation (for example, with setInterval) will not succeed since we’re only able to fire our psuedo-event after the change.

The following example shows how you would use watch() - at no time does the property actually change to ‘456′, it’s constantly ‘123′:

var obj = { prop: 123 };
 
obj.watch('prop', function(propertyName, oldValue, newValue){
    return oldValue;
});
 
obj.prop = 456;
 
alert(obj.prop); // 123

Additionally, watch() does not recognise internal property changes (within the DOM). If you setup a watch on the value property of an input element, even when you type into that field, your watch-handler will not execute. I’m not sure if this is intentional but it makes this technique entirely useless for monitoring DOM properties.

So, it appears that the only way to monitor DOM properties consistently across all browsers is to only use setInterval. The following plugins, watch and unwatch work quite well:

jQuery.fn.watch = function( id, fn ) {
 
    return this.each(function(){
 
        var self = this;
 
        var oldVal = self[id];
        $(self).data(
            'watch_timer',
            setInterval(function(){
                if (self[id] !== oldVal) {
                    fn.call(self, id, oldVal, self[id]);
                    oldVal = self[id];
                }
            }, 100)
        );
 
    });
 
    return self;
};
 
jQuery.fn.unwatch = function( id ) {
 
    return this.each(function(){
        clearInterval( $(this).data('watch_timer') );
    });
 
};
 
// Plus, I finally found use for jQuery.data()! ;)

These can be used on any type of object, an example:

$('input').watch('value', function(propName, oldVal, newVal){
    log('Value has been changed to ' + newVal);
});
 
// or...
 
var obj = { prop: 123 };
$(obj).watch('prop', function(propName, oldVal, newVal){
    log('Prop has been changed to ' + newVal);
});

I went ahead and created a new special event for jQuery using the plugin:

jQuery.fn.valuechange = function(fn) {
    return this.bind('valuechange', fn);
};
 
jQuery.event.special.valuechange = {
 
    setup: function() {
 
        jQuery(this).watch('value', function(){
            jQuery.event.handle.call(this, {type:'valuechange'});
        });
 
    },
 
    teardown: function() {
        jQuery(this).unwatch('value');
    }
 
};
 
// Usage:
$('input').bind('valuechange', function(){
    log('Value changed... New value: ' + this.value);
});

This event is useful when you want to be notified every single time the value of an input element changes. No native DOM event will do this.

If there’s one thiing you should take away from all this then it’s this: if you are going to try making a browser-specific feature available across all browsers you should make sure that you match the functionality precisely, otherwise it’s worthless. For example, an Array.prototype.forEach method that passes the index as the first parameter instead of the second is useless. If you can’t match the functionality then simply create your own abstraction.

Apparently IE8 considers itself more secure and easier to use than other browsers too!

I can’t even begin to express my absolute opposition to every speck of misinformation on that chart. How dare Microsoft mislead consumers to such a degree - I know they put financial superiority and their monopoly above all other human values but this doesn’t excuse their flagrant disregard of their customers’ intelligence.

Consumerism is only good for one thing in my opinion - creating arrogant, possibly corrupt and more annoyingly, ignorant individuals. The people running Microsoft and the various departments involved must either be unquestionable morons or just so manipulated by the culture of consumerism, personified solely by that retched corporation, that they are beyond help!

In the past I’ve been quite calm and civilian in my dealings with the atrocity known by some only as “IE”, but now I feel a new spark of anger has been born; Microsoft has forever lost my respect and confidence in the prospect of change.

I know, I know! Marketing and advertising, it’s all about lies, spin and manipulation… But, that doesn’t mean it’s right, and yes, there is room in our capitalist cultures for honesty.

I want to have a long and hard chat with the heads of the IE team; I’d love to hear their twisted take on reality - maybe one of them could shed some light on the unacceptable marketing drivel that’s been circling the net, which, by the way, not only includes the chart I mentioned, but check this out! Yes, not only are Microsoft capable of releasing lies in the form of propaganda but they’ve also developed a system that will insult the browser you’ve chosen to use unless, of course, you’re using Internet Explorer, but then why would you?

The marketing team responsible for the latest scam should publicly apologize and then be permanently banned from every touching (or speaking about) anything remotely related to technology again!

It’s fair enough when Microsoft slam their own previous products but attacking Google Chrome and more shockingly, Mozilla Firefox, is way below the belt!

• A fully customizable zoomer for use with any image
• Works in all modern browsers (including IE6 )
• This is a progressive enhancement; images will still be viewable when JavaScript is not available.
• The Zoomer itself is highly customizable.
• The Zoomer requires NO images – the shadows/gradients are dynamically generated by JavaScript (using VML /Canvas technologies)
• In-depth documentation including two videos and an FAQ !

See the demo

It’s customizable!

Almost every aspect of the zoomer is customizable, here’s a preview of the jQuery options:

$.zoomer.defaultOptions = {
    zoomerClass: '_zoomer',
    zoomSrc: '',
    height: 150,
    width: 150,
    mousewheelZoom: true,
    defaultZoom: 2,
    maxZoom: 5,
    minZoom: 1,
    feedback: function(x,y,zoom){},
    onOver: function(){},
    onOut: function(){},
    zoomerOverlay: {
        className: '_zoomer-overlay',
        shadowWidth: 10,
        shadowOpacity: 0.5,
        /* Must be in "rgb(r,g,b)" format */
        shadowColor: 'rgb(0,0,0)',
        radialOpacity: 0.4,
        /* Must be in "rgb(r,g,b)" format */
        radialColor: 'rgb(0,0,0)'
    }
};

Even the shadow beneath the Zoomer is customizable - this is possible thanks to canvas/VML technologies.

Buy Zoomer (currently $5)!

With this technique you can do the following:

<div id="foo">
    <!-- { someData: 123, aString: "bar" } -->
    <p> ... regular content ... </p>
</div>
 
<!-- Regular comments can still be used -->
 
<p><!--{specialID:1234}-->... comment-data is tied to the parent element...</p>

Using the “commentData” function you can extract that information and use it within your JavaScript, e.g.

var foo = document.getElementById('foo');
 
var fooData = commentData( foo ); // => {someData: 123, aString: "bar"}
fooData.someData; // <= 123

Download “commentData” from Github

Have you ever needed to do this? -

// E.g. 1
element.addEventListener('click', function(e){
    this.rel += ' clicked' + '(' + e.clientX + ' ,' + e.clientY + ')';
});
 
// E.g. 2
jQuery('a').mouseover(function(){
    var color = jQuery(this).css('color');
    jQuery(this).data('beforeColor', color);
    changeColor(this);
});

If you have then (in my humble opinion) you’re abusing the DOM!

The first example is obviously bad practice; using HTML attributes to track changes unrelated to the HTML content is a crime of sorts and should never be done! The second example probably doesn’t seem as bad to most developers. jQuery’s “data” method allows you to store expando-like data about an element without obtrusively defining it as a direct property. This technique of storing element data is far better than using the HTML rel attribute. Or is it?

I was an advocate of this particular technique but I’ve come to realise that it is, in most situations, no better than using any random HTML attribute. If we put the unobtrusive-vs-obtrusive argument aside, both techniques are effectively the same. Plus, jQuery’s “data” technique is not really unobtrusive - jQuery still uses an expando property to tie the element to a particular property in a JavaScript object; I’m not saying there’s anything wrong with this, I’m just pointing out the common misconception that using jQuery’s data method is somehow cleaner than using a random or made-up HTML attribute (/DOM property).

The main reason I am now so sceptical about its usage is because, over time, I’ve seen a lot of cases that don’t really require it at all and could quite easily be achieved with a well-thought-out use of JavaScript closures. Obviously it’s not all bad; there are a few valid uses - for example, jQuery currently uses its own “data” method to tie events to elements/objects; a central part of the its event dispatch system.

Magical closures

The nature of JavaScript closures allows us to use regular variables to store progress or states and then access those variables from within nested functions. I’ve put together a short example; this is an outline of a drag-and-drop script:

// Library neutral/agnostic
 
draggableElements.forEach(function(elem){
 
    var down = false,
        y = 0,
        x = 0;
 
    elem.bind('mousedown', function(e){
        down = true;
        x = e.pageX - getOffset(elem).left;
        y = e.pageY - getOffset(elem).top;
    });
 
    document.bind('mousemove', function(e){
        if (down) {
            elem.applyCSS({
                left: e.pageX - x,
                top: e.pageY - y
            });
        }
    });
 
    document.bind('mouseup', function(e){
        down = false;
    });
 
});

Every “draggable” element is given its very own closure (through forEach) within which we can define numerous variables accessible in each of the nested “handler” functions (’mousemove’, ‘mousedown’, etc.). No expando properties are required, nada!

I haven’t got much more to say about this; the above code pretty much sums up my point!

I’m interested in valid uses of jQuery’s data() method (other than those used in the core); someone please enlighten me!

In some ways JavaScript could be considered just as lax as HTML when it comes to what is acceptable and what isn’t. For example, most browsers will let you get away with HTML that looks like this:

<ul
id =list>
    <strong><li>One
    <strong><li>Two
    <strong><li>Three

And, similarly, most, if not all, browsers will let you get away with JavaScript that looks like this:

function muahaha() {
    myarray = new Array()
    myarray['name1'] = "056"
    something = parseInt( myarray['name1'] )
    if(something==56)
        for (i=0;i<myarray.length;i++) if(myarray[i] != null) return true
    return false
};

How many things can you count in the above code that are either bad practice or just incorrect usage of the language? If we go by JSLint then there are a total of 16 problems with it! Plus there are a couple that aren’t noticed by JSLint (using an array as an object & accessing myarray.length on every iteration). That’s 18 altogether! Yet, all browsers will run this code quite happily without throwing a single error.

Technically, it’s all legal JavaScript (minus the extra semi-colon at the end), so I’d expect all browsers to munch it up without complaining.

So, if it works¹, then why should you take that extra step to ensure best practices; what’s the point and who will benefit?

For starters, there’s you! When you need to maintain or add to this code you’ll find yourself spending many more minutes doing so than if the original code has been written with best practices in mind. Although, honestly, you are the last person that you should be worrying about. What on earth is another developer going to make of this?

Good practices exist for a reason; not following them generally leads to bad things. Don’t use JSLint because you have to, use it because you want to!

¹ - The function won’t work as expected (parseInt('056') !== 56) but it will “work”; as in, it won’t throw any errors. Actually, just completely ignore the muahaha function; it doesn’t do anything; it’s just an example of awful code.