Visit the Before/After plugin page to download the latest version and try out the demos.

The jQuery

After the jQuery code to instantiate the plugin, add (assuming a container with the id of “conjainer”):

$('#container').prepend('<p id="loader">Loading...</p>');
$('#container > div:eq(2) > img').load(function() {
	$('#loader').remove();
});

The CSS

Then add some styling. Here we’re adding an animated loading gif:

#container {
	border:2px solid #666;
}
#loader {
	background: #e9e9e9 url(ajax-loader.gif) no-repeat 50% 50%;
	margin:0;
	padding:0;
	width:100%;
	height:100%;
}

And that’s it! Note that this is just a basic example and it only tests for one of the two images being loaded, however it’s basic to extend this concept further and even provide more feedback to the user.

About a year ago I was asked to create a plugin that allowed visitors to navigate a series of web pages without having to ever actually leave one page. What I came up with I’m calling the Page Carousel plugin. The Page Carousel allows you to take an unordered list and turn each item into its own page.

Features:

• Turns an unordered list into a web page carousel. Have an entire website run from one page.
• Each “page” is bookmarkable and can be linked to directly
• Shortest path algorithm finds the shortest path to the selected page. For example, in a seven page site if you navigate from page 2 to page 7, the carousel slides to the right three pages instead of to the left five pages.
• Peek effect. Allows users to see part of the previous and next pages.
• Keyboard navigation. Use the left and right arrows to navigate.
• Customizable navigation links and arrow images.
• Resizes with browser.
• Separate left/right easing effects
• Callback functions
• Degradable. No JavaScript? No problem!

Download

• jquery.pagecarousel.js (13k)

Demos

• Example 1 – Small peek applied
• Example 2 – Embedded video and alternate navigation options

View each demo’s source code for options and styling.

How to Use

Build an unordered list and wrap it in a div with an ID. Point to jQuery and the plugin (using an easing plugin is optional):

<script type="text/javascript" src="jquery-1.6.2.min.js"></script>
<script type="text/javascript" src="jquery.easing.1.3.js"></script>
<script type="text/javascript" src="jquery.pagecarousel.js"></script>
<script type="text/javascript">
$(function(){
    $('#container').pageCarousel({
        nextPrevImagePath: 'images/nextprev.png',
        transitionSpeed:500,
        padding:'10px',
        peekAmount: '20px',
        showLinks: true,
        pageWidth: '800px',
        linkPosition: 'top',
        easeLeft: 'easeInOutExpo',
        easeRight: 'easeInOutExpo'
    });
});
</script>

A namespace is essentially a wrapper for your code’s variables, functions, constants, and classes. This wrapper prevents “collisions” (a.k.a. clashes, conflicts, etc.) with other people’s code. For example, if you grab a script from a site and drop it into your web page you might find that for some reason that the script doesn’t work. Or you may discover that code you wrote, which worked before you dropped in this new code, has stopped working. After doing some debugging you determine the problem stems from both you and the person who wrote the script you grabbed are using the same variable names purely by accident. Your code works fine on its own, as does this script you grabbed; however because you both inadvertently used the same name for a variable, one of your variables is being overwritten by the other. For example, you both may have used a variable named firstName. Now while this might not be hard to fix, it can be time consuming and frustrating to track these kinds of errors down. Plus, simply renaming the conflicting variables can lead to other errors springing up. With more and more developers writing code to be shared, the odds only increase that someone will step on someone else’s code. This is where namespaces come in.

Namespaces basically wrap all your variables in a tidy package so that you can use whatever names you like without them colliding with someone else’s variables. A key step is to give your namespace a unique name because if your namespace has the same name as someone else’s namespace, well pretty much the universe will implode on itself. But fear not, it’s far easier to change a namespace’s name in the event of duplication than it is to replace all the instances of one or more variables in your code.

Again, while namespaces are not required, they can be an extremely valuable tool.

JavaScript Namespaces

By default, variables in JavaScript are global in scope unless they’re defined within a function using the var declaration. This means that you can access a variable anywhere in a script since they are within the global namespace. Variables defined within functions using the var declaration (e.g. var foo = 2;) are only accessible from within that function. By creating your own namespace you segregate your variables from the global namespace and prevent other code from accidentally accessing them, similar to the way using the var declaration in a function segregates that variable from being accesses from outside of that function. If you and I both write code that use a variable named firstName and then include both scripts on the same page, one of the scripts will overwrite the other’s use of firstName. As the book JavaScript the Definitive Guide states, “If you want to write a module of JavaScript code that can be used by any script and can be used with any other module, the most important rule you must follow is to avoid defining global variables. Anytime you define a global variable, you run the risk of having that variable overwritten by another module or by the programmer who is using your module. The solution instead is to define all the methods and properties for your module inside a namespace that you create specifically for the module.”

One of the easiest and most widely-used methods for defining your own namespace in JavaScript is to use an object. For example,

var superspace = {};

creates an empty JavaScript object which can then be used as our namespace. In the past we might assign a value to our firstName variable like

var firstName = "John";

however by using an object we can now do the same thing via

superspace.firstName = "John";

You can also place functions in your namespace object in a similar way. For example,

superspace.getFirstName = function() {
return superspace.firstName
};

The only real difference when using namespaces is that you prefix the name of the namespace object (superspace) to the variable name. This little change is what allows us to encapsulate our variables and keep them protected. It’s also possible to create your namespace object and your variables and functions at the same time. For example, using the same code as before you could write:

var superspace = {
    firstName : "John",
    getFirstName : function() {return superspace.firstName}
};
document.write(superspace.getFirstName()); // outputs "John"

Now, superspace.firstName and superspace.getFirstName are available globally within our page, however collisions won’t occur unless someone else is also using an object with both the same name (superspace) and the same variables (firstName and getFirstName).

Another way to create a namespace is through self-executing or self-invoking functions. Self-executing and self-invoking functions are simply anonymous functions (no explicit name) that are executed immediately after they are read by the browser. For example:

var superspace = (function() {
var firstName = "John";
var getFirstName = function(){return firstName};
    return {getFirstName:getFirstName};
})();
document.write(superspace.getFirstName()); // outputs "John"

A self-invoking function is a normal function, just with a set of parentheses appended to the end. The set of parentheses at the end tell the browser to execute the function just as if you were invoking a normal, named function (e.g. getFirstName();). Since self-invoking functions aren’t reusable, they’re really not functions in the truest sense since functions are meant to be reused. To differentiate self-invoking functions from normal functions, it’s recommended that self-invoking functions are wrapped in parentheses. To be honest, I prefer the simple object method of namespacing over the self-invoking function method because it’s easier to read and needs less code to accomplish the same task.

Update (July 22, 2011): This kinda pisses me off. Apparently Google is dropping support for the Google Toolbar in Firefox 5+ (“Therefore, while Google Toolbar for Firefox works on versions up to and including Firefox 4 only, it will not be supported on Firefox 5 and future versions.”). I’m not just pissed that I’m losing a bunch of functionality I use every day, but now I have to hunt and peck to cobble together replacements for the tools I use every day. Thanks a lot Google.

Source: http://googletoolbarhelp.blogspot.com/2011/07/update-on-google-toolbar-for-firefox.html

Update (October 7, 2011): Someone over at optimize-your-pc.org discovered a nice hack to get the toolbar working again in FF7! All it takes is two quick modifications to some files for the toolbar and you’re back in business. Worked for me in Windows 7 and XP. Check it out at http://www.optimize-your-pc.org/use-google-toolbar-on-firefox-6-and-7.

This new release features:

• Several new options. You can:
  • Set the starting horizontal position of the draggable divider
  • Set the text for the before/after links
  • Set the cursor style
  • Set the speed of animation when clicking an image
  • Set the speed of animation when clicking a link
  • Set the color of the divider
  • onReady callback function
• jQuery and jQueryUI draggable are now bundled with the plugin for those that don’t want to, or can’t use, a CDN.
• Tighter code (6.7 Kb uncompressed, 4.5 Kb compressed).
• Compatible with jQuery 1.6.1

Notes:

• The CSS classes for the span tags that wrapped the text links have been changed from “bflinks” to “balinks”.
• The requirement to have each image nested within a div tag has been removed; however the plugin will still work if you use that structure.
• The previous version of the plugin took the images and made them background-images within div because of issues with webkit browsers and jQuery at the time. Those issues no longer exist so the original functionality of using the images as-is has been restored.

I’ve created a dedicated page for the plugin at http://www.catchmyfame.com/catchmyfame-jquery-plugins/jquery-beforeafter-plugin/. In the future this page will be updated to contain the latest information for this plugin.

Or if you just can’t wait, download version 1.3 here.

I plan on adding a post in the upcoming days about how you can add a few lines of code to enable a simple “loading, please wait” feature if you’re using the plugin with large images that may not load quickly.

Finally, while this version of the plugin doesn’t have touchscreen support for mobile devices, I do plan on adding that feature in the future. jQuery’s touch library is still in alpha and seems a bit quirky, and other libraries also have their issues. I’d prefer to avoid libraries for such a small amount of functionality so that the size can be kept down, so feel free to post suggestions on how to best accomplish this.

Enjoy!

I’m currently working on a project that uses jQuery throughout the user interface to improve the user’s experience. In one section of the application there are three divs laid out next to each other horizontally as if they were three columns. The leftmost div contains a series of items to select from via check boxes. When you pick one (or more) items, the middle div is populated by a jQuery Ajax query and displays a list where the content is based on what was selected in the first (leftmost) group. Finally, you can click on an item in the middle div which will then bring up detailed information in the rightmost div.

Normally this wouldn’t be a problem, but in this case the issue is that the width of the columns needed to be dynamic. If we had made the column widths fixed, then whenever the data in any of the columns was wider than the containing div, a horizontal scrollbar would’ve popped up. While this wasn’t a showstopper, it’s wasn’t visually appealing. You might be thinking that using a table would be a good solution except for the fact that resizing table cells isn’t much easier than resizing multiple divs, plus we’re not displaying true tabular data. Another possible answer could lie in using frames, except for the fact that frames disappear in HTML5 and I haven’t used frames in over 10 years.

So back to our divs. To find a solution I realized that not only would I need the three main div containers, but I would also need two more divs to act as column separators. These two new divs should give me something to grab and drag since dragging the left, middle, and right container divs themselves wouldn’t look right.  OK, so now we have five divs laid out horizontally. Three for content and two to act as drag handles.

So we have our layout but the real brain work still needed to be done. How can I manage all the divs so that only the two “handles” were draggable AND the three content divs would respond to the movement of either handle? By using jQuery I could make the two handles draggable – that was easy. The problem now was how to get the content divs to react to the handles being moved. After many failed experiments, I determined how to properly arrange the divs so that dragging the handles not only properly resized the container divs, but the handle divs were prevented from overlapping each other.

During some of my initial experiments I would drag the handles and the neighboring content divs would be resized, but they ended up pushing my handles while they were being dragged making them move much farther than they should have. After positioning the handle divs absolutely that solved the ghost movements, but introduced another problem. With the handles positioned absolutely, they had been removed from the flow of the document so I couldn’t rely on their dimensions and other CSS attributes to “push” the other content divs. Now I had to calculate their position and use that information to resize the other div’s width. When dragging the left handle we would change the width of the left and center content divs. When dragging the right handle we would change the width of the center and right content divs. There wasn’t any need to change the left position, margin, or padding for any of the elements and this was a big relief.

Not to go into too much technical detail, but jQuery’s draggable interaction has a containment option which allows you to restrict the movement of draggable elements. This would be critical to prevent the handles from being dragged too far. The problem is that you either pass it an element, like the parent of a draggable element, the body of the page, or give it a set of coordinates. The problem with the coordinate system is that it’s relative to the document, not an element. Had we been able to specify the coordinates relative to an element rather than the document, this would’ve been much easier.  Since we had to use coordinates relative to the document we had to make our calculations relative to the document as well, which caused a conflict with webkit browsers when we wanted to center our columns. The problem with webkit browsers is that they don’t calculate the jQuery offset() function properly when you center something by using margin: 0 auto and you have a whole slew of “how am I ever gonna get this one to work?” problems to solve. Once I figure out that by solving the webkit centering issue I wouldn’t have to worry about the offset() issue it was smooth sailing.

Another issue involved the content divs themselves. Floating them didn’t work and absolute positioning didn’t either.  I began to dig into the CSS display property. Did you know that the display property can be:  block, inline-block, inline-table, list-item, run-in, table, table-caption, table-cell, table-column, table-column-group, table-footer-group, table-header-group, table-row, or table-row-group? Neither did I. As it turns out, inline-table did the trick. (Note: I later found out that inline-block also works just fine.)

The W3C says that the inline-table property is “a rectangular block that participates in an inline formatting context”. This basically means that you can have a block with a width, height, margins, etc. but it’s treated as an inline element instead of the usual block element. Hmmm. So far so good. Add that, width, and a little vertical-align:top to all the container divs and we’re looking good. The handle divs get positioned absolutely and get their left position set initially based on the container divs to their left (i.e. the first handle has a left position equal to the width of the first container div and the second handle has a left position equal to the width of the first two container divs plus the width of the first handle. That’s all the CSS you need, the rest is jQuery.

Since we can’t center the big div that contains everything and do our dragging because webkit browsers can’t calculate the correct jQuery offset, we center it manually (note that this isn’t necessary if you’re not going to center the whole shebang). Then we have to figure out the horizontal limits of our drag handles. We don’t want to have people dragging the left handle over the right handle and vice versa, plus we should also give the content divs a minimum width so that the content doesn’t become unreadable. Finally we calculate the containment area for each draggable handle once the opposite handle is finished being dragged. Phew.

Finally, this code is pretty compact and works in all browsers including IE8. It doesn’t work in IE7 or IE6 and that’s just fine with me. It also degrades well for those with JavaScript disabled. Check out the demo and feel free to play with the code. If you come up with a more elegant solution or use this in a project of your own feel free to share it.

View the demo here

The first time you visit the page you see what appears to be a normal home page

Notice that the vertical scroll isn’t at the top of the page? It’s almost imperceptible and in fact, I didn’t notice it for a week. Why does this happen? Scroll up the page and you’ll see that msnbc.com now has a large chunk of content sitting up above what appears to be the normal top of the page. It wasn’t until I saw a link where some of the old navigation used to be that said “Where’s my navigation? We’ve moved it to the top” that I noticed this big change.

So I have to ask why would you redesign a page and place a large chunk of important content up above where the visitor will see when a page loads so that they have to scroll up to see it? This just seems completely counter intuitive to web navigation. Visit a news site and then scroll up to read the headlines? That’s like opening the New York Times and then finding that the top stores section was folded down behind the front page.

Msnbc.com explains this change by saying “We’ve moved the news menu to the top of story pages and made it easier to see what’s happening across the site. When you first get to a story, you’ll see sections and shows displayed across the top of the page. Below is the name of the section you’re in and a search box. Scroll up to see top headlines, slideshows, video and hot topics. Roll over a section name to see more from that section and click on a section name to go there.” Scroll. Roll. Click. Are they serious? Is it just me?