Everything in the tutorial is exactly as it was on my site at the time of writing. However, this is no longer the case. Over the weekend I got a tweet from William Flake indicating a modification he made to the code to prevent a “jump” that occurred when you first moved the mouse into the header. I liked his alterations so much that I’ve made use of them in my code.

This week William wrote about his code alterations over at his site Unfinished Thoughts in a post entitled Of Squirrels and Men. If you enjoyed my parallax code, please take a look at what changes he made. They’re definitely worth a gander.

The very short answer is: with JavaScript and CSS.

Of course, that’s not a very satisfying response, so I’ll go ahead and expound a bit more. I did it in three steps. First, creating the right group of images. Secondly, with some simple CSS and HTML. Lastly, with a surprisingly short JS script.

Step 1: The Images

The first step for parallax scrolling, in any application, is having multiple layers of images to scroll at different speeds, with each layer representing another part of the passing landscape. In the case of this site, I’ve got four: clouds, mountains, hills, and forest. By themselves, neither layer looks terribly interesting.

Layer 1: Clouds

Layer 2: Mountains

Layer 3: Hills

Layer 4: Forest

They’ll have to be stacked over each other, so in order to be seen through one another they need to have transparency. This is why I used PNGs (although depending on the type of art you use, GIFs are fine).

Step 2: The CSS and HTML

Next, the images will have to be stacked over each other. I made four empty divs which I put in the header/branding div as follows:

<div id="cloudLayer" > </div>
<div id="mountainLayer" > </div>
<div id="hillLayer" > </div>
<div id="forestLayer"> </div>

Although I’m not normally a fan of non-semantic divs, for this special effect I need something to hang the imagery upon. These four divs will be what we need for the CSS:

div#cloudLayer, div#mountainLayer, div#hillLayer, div#forestLayer {
 height:200px;
 position:absolute;
 text-indent:-9999em;
 width:100%;
}

div#cloudLayer {
background:transparent url(images/clouds.png) repeat-x scroll left top;
opacity:0.6;
}

div#mountainLayer {
background:transparent url(images/mountains.png) repeat-x scroll left top;
}

div#hillLayer {
background:transparent url(images/hills.png) repeat-x scroll left top;
}

div#forestLayer {
background:transparent url(images/forest.png) repeat-x scroll left top;
}

So each div is set at the same height, as wide as the parent element (the header), and absolutely positioned so they all overlap. Each background image is set appropriately to repeat horizontally along the layer it is within. If nothing further was done, this would be a complicated way to create a repeating landscape background. Only one small bit is left to make it scroll.

Step 3: The JavaScript (with jQuery!)

I love jQuery. It’s a convenient, compact JS library that makes cross-browser coding easy and compact. You could probably do this script without it, but by necessity it’d be a lot larger. Here’s the part of my script that controls the scrolling:

$('#branding').mousemove(function(e) {
mouseX = e.clientX;
$('#cloudLayer').css('background-position', Math.floor(mouseX / 4) + 'px 0');
$('#mountainLayer').css('background-position', Math.floor(mouseX / 3) + 'px 0');
$('#hillLayer').css('background-position', Math.floor(mouseX / 2) + 'px 0');
$('#forestLayer').css('background-position', mouseX + 'px 0');
});

I want the scrolling to only occur when the mouse is over the header, which is a div I call branding. So I’ve bound the .mousemove() event handling function to that div. I get the x-coordinate of the mouse when that even fires (anytime the mouse moves) and then adjust the background image positioning on the layer divs accordingly.

If I moved each layer’s background image by the same amount, the image would scroll all at once, and there’d be no parallax effect. Therefore, I instead divide the x-coordinate by a different amount for three of the four layers, moving each background image an increasingly smaller amount for the “far” layers.

The finished result is visible in the header above!

As always, if you have any comments or questions, feel free to share.

I’m working on a side-project that has multiple instances of the same object (or the equivalent in JS) that makes use of jQuery’s .animate function. At the end of the animate function I want to use .animate‘s callback function option to loop the function in each object (allowing each to loop through a frame-by-frame animation of its own, for example).

The problem is I’m running into an obstacle, which can be illustrated by this simplified looping example. In this particular case, when you click on the button, it creates an instance of the object, sets a value inside it, then calls an internal function which displays an alert box, then calls a (in this case pointless) jQuery .animate function which contains a callback function to loop the instance’s function. The idea would be that I can call multiple instances of the object, and have each assigned their own values and then they’ll loop happily on their own.

That’s not happening, of course.

If you examine the JS source code (linked here) you’ll see that I use function(){this:greet();} as my callback parameter. My understanding was that this would correctly relaunch the function of the instance. It does not, however, work as I desire (aka, at all).

I know that this is an odd thing, so I’m sure I’m hamfistedly trying to pound a square peg in a round hole. The trouble is that I have absolutely no clue what the round peg is.

What I really need is a Master Po to tell me where I’m going horribly wrong here. Can anyone be my blind kung fu mentor?

As plenty know, Lightbox is a convenient and quick solution to providing a slightly glossy gallery effect for a page of photos or artwork. I personally prefer jQuery Lightbox, mainly because I’m a jQuery addict, but there is a slight issue with it being used in sites that have a fixed width on the body element (which I try not to do myself, since who knows what the end-users monitor is going to be like, but for client sites  I don’t always have that freedom).

The issue is illustrated in this example here: the dark-background overlay that appears to cover the page doesn’t go past the margin of the body, leaving distracting bright gutters that ruin the desired effect.

In cases where you need (for whatever reason) a fixed body width, the solution here for jQuery Lightbox is fairly straightforward, but involves a wee bit of modification to the jquery.lightbox.js file’s code.

Inside the file, find the _set_interface() function and look for this segment of code:

            $('#jquery-overlay').css({
                backgroundColor:    settings.overlayBgColor,
                opacity:            settings.overlayOpacity,
                width:                arrPageSizes[0],
                height:                arrPageSizes[1]
            }).fadeIn();

We need to change it to the following:

            $('#jquery-overlay').css({
                backgroundColor: settings.overlayBgColor,
                opacity: settings.overlayOpacity,
                width: $(window).width(),
                height: arrPageSizes[1],
                left: -(($(window).width() - $('body').width()) / 2)
            }).fadeIn();

Why is this? Let’s focus on the changes.

The width has been changed to $(window).width() so it actually gets the width of the browser window, and not just the body element, across all browsers (the provided value only provides the body element width in IE, Webkit, and Opera). Without this, the overlay won’t get wide enough to cover everything up.

The new value, left, gives the css style that will position the overleft to the left side of the screen by subtracting the difference of the browser’s width and the body’s width. This will allow it to work for all browser sizes.

Lastly, we need to put overflow: visible on the body element in our CSS. With this, we can see the overlay when it goes outside the body’s borders.

With these tiny changes in effect, check out the new result here. Much better, isn’t it?

What is Cufon? Cufon is a plugin-free, Javascript-powered alternative to rich font embedding. In particular, it’s a great alternative to flash-powered sIFR, which prior to Cufon was the best way to get rich font support during our long desert of poor font-embedding support that is the modern web.

By “great alternative”, I mean that it “lights sIFR on fire, kicks it into an open sewer, and laughs maniacally as sIFR rolls around in stinky, burning pain.”

Yes, it’s that much better. And if you don’t agree, I’ll punch you.

Ok, that’s not true. I’m opposed to violence. I also never learned how to throw a punch, and I’m worried that I’d break my thumb.

However, it is better. For three major reasons. 1. It doesn’t require you to own Flash to build the font file you’ll be using. 2. It doesn’t require a plugin in your browser to work (aka, it works on iPhones among other things). Lastly, 3. It’s way, way faster.

It’s things like Cufon that convince me that in the near future that Javascript will be the new Flash. (canvas and SVG make my pants tight in an embarrassing way.)

How does Cufon work? Simple.

1. Visit their site. Download the cufon script. Include that in the head of your page.

2. Get a font, and using their nifty generator, turn it into a .js file. (Supports several standards, including OTF and TTF.) Link that font script in the head of your page after the cufon script.

3. Do an air guitar riff. (Optional.)

4. In a script you add, include a  command to the effect of Cufon.replace(“elem”) where elem is the element you want the font to replace. If you’re only using one font with Cufon, it’s as easy as that. If you’re using multiple fonts, you’ll need to do Cufon.replace(“elem”, “font name”), where “font name” is the name of the font you want that element to use for that element.

5. Look on in awe as the font are replaced so fast, your page will go slightly back in time.

An example of a finished result is right here. It’s simple, but it gets the point across.

Like sIFR, I can’t recommend using the font replacement on large fields of text. Selecting the text for copy/paste purposes is difficult (although not impossible), and it’s bound to have an impact on performance if you use it too widely. But selectively used it can open your projects open to a cornucopia of fonts (licenses allowing.)

What are you waiting for? Go get it now!

1. RDFa – Yes, the syntax is complicated at first. But the next phase of the web is symantic, and microformats, though convenient, are only a stopgap issue, and RDFa will be a powerful way to express relationships for computers.

What really irks me is that HTML5 won’t support RDFa because Ian Hickson opposes them, and he functions as the sole gatekeeper to the standard. This annoys me on a number of levels: why is a web standard that will effect billions of future sites being controlled ulimately by one person; and why would someone seriously think the leading semantics format we have not be needed for a web that is clearly and rapidly heading towards a Semantic Web?

I’ll rant more on that in the future.

2. Accessibility – there’s a lot of things that I’ve been doing right for accessibility, but Derek Featherstone pointed out a lot of potential pitfalls with AJAX that I need to start payingca lot of attention to.

Ok, the writing on my phone is driving mad, so I’m going to sign off now. More later!

The situation: I’ve got an empty imagemap that I want to dynamically enter area tags into with jQuery. I’ve been trying to insert them using .append() or even .html() and every time I attempt to do so nothing occurs. I can insert text or other tags, but no actual area tags.

Now, if I go oldschool and use document.getElementById(insertnamehere).innerHTML = “inserttagshere” that works. But every variation I can think of to use jQuery methods to add an area tag fails.

Can anyone think of anything obvious that I’m missing here?

“I’m absolutely going to use it and recommend its use far and wide.”

Sounds pretty excited to me. What is all this enthusiasm being caused by? What is Sizzle?

I’m still catching up on the details as I write this, but in essence it’s a JavaScript project that will take advanced CSS selectors (read that, CSS3 selectors with little to no current browser support), do some work behind the mysterious veil, and then spit out the results on the browser. Any browser.

As a designer all you’d have to do is write your stylesheets with these new selectors (and possibly new properties like multiple-backgrounds, although I’m still confirming that), and let JS do the rest.

This is hot. It’s taking all the work that has been put into making JS engines these days smokingly hot, and converting that effort into some benefit for CSS, which isn’t getting the same fast-track treatment we’ve been desiring. I goofed around with a similar concept with a pseudo-class to class CSS converter called Pseudonut, but this is a whole other beast, and I’m really looking forward to it.

I don’t know if this is a problem in other libraries, but I suspect it is. But I do know that it’s happened to me when using jQuery’s Ajax functions.

Why is this occurring?

I was tormenting myself with this same question on a client project, and discovered that although a bit of browser quirkiness was involved, it was actually an error on my part.

I hate it when it’s me. ;)

As it turns out, I had an extra trailing comma at the end of the last element in my array. For example, in the following array:

{“gamesImDroolingFor”:[{"developer":"Blizzard","title:"Diablo III"},{"developer":"Square Enix","title":"Final Fantasy XIII"},]}

You’ll notice that there’s a comma after the last game’s bracket (which has been turned red for emphasis).

Firefox will ignore that comma, since clearly there’s no new object after it. Internet Explorer, the special child of the web, isn’t quite so bright, so it adds an extra, blank element to the array it creates.

Go IE.

The solution is easy, of course. Remove the unneeded comma.

I hope this helps prevent other developers from driving themselves batty trying to figure out what’s going wrong with their own arrays.