I'm really digging it so far. Python's syntax is ultra-clean and easy to learn, and as far as I can tell, Django lives up to its promise of rapid, scalable application development. I've always shied away from the major PHP frameworks, which strike me as bloated and over-complex—but working with Django has been an entirely different experience. It takes care of all the repetitive grunt work, so you can focus on the creative stuff and the big picture.

It'll be a while before my Python skills are up to speed with my PHP skills, but I can definitely see myself adding Python to my daily toolbox—or even switching to Python as my primary language.

This is remarkable for a browser that still claims a double-digit percentage of the market. Businesses don't willingly shut out ten percent of their potential customer base, unless that ten percent is an enormous pain in the ass.

It's also exactly what needed to happen. The main reason IE6 is still alive is that corporate IT departments have been reluctant to upgrade from aging Microsoft enterprise software that doesn't work in modern browsers. By unilaterally dropping support, web developers are forcing their hand.

Sorry, guys—I know that major version upgrades of mission-critical enterprise systems aren't fun (or cheap). But you're holding back the web, and you're making an awful lot of extra work and frustration for web developers and their clients. IE6 is almost a decade old, and it's been superseded by two major versions, with a third—IE9—in public beta. It's time to move on.

Once IE9 is in general release, I suspect very few developers will continue supporting IE6.

What about IE7? It's far superior to IE6, but still dodgy. Fortunately, the situation that has kept IE6 around for so long—a widely installed base of expensive-to-replace software that only works in one browser—doesn't apply to IE7. With IE6 in the grave, IE7 can fade away much more gracefully.

We'll probably have to support it for a while yet—there will always be those users who don't know what a browser is, much less how to upgrade one or why they should do so. But IE7 won't be around a decade from now.

Who knows? A few years from now, maybe I'll even remember IE6—in all its neurotic naïveté—with fond nostalgia, as I now remember Netscape 4. Maybe.

It works the other way, too—an object can be cast as an array.

This is especially useful when working with the results of database queries. A lot of codebases seem unsure whether to treat database rows as arrays, or as objects. In these environments, it's likely that you'll get one type as the return value from a particular method, but need to pass the other type as an argument to a second method.

So it's nice to have a simple and language-native way to convert between the two. Some simple demo code:

<?php
 
// create an array
$array = array(
	'prop1' => 'value1',
	'prop2' => 'value2'
);
 
// cast it to an object
$object = (object) $array;
echo 'The value of the property prop1 is: ' . $object->prop1 . '<br />';
echo 'The value of the property prop2 is: ' . $object->prop2 . '<br />';
 
// cast it back to an array
$array2 = (array) $object;
echo 'The value for the key prop1 is: ' . $array2['prop1'] . '<br />';
echo 'The value for the key prop2 is: ' . $array2['prop2'] . '<br />';
 
?>

Now I've discovered a similar collection of articles by Peter Michaux. They often riff on Crockford's ideas, sometimes offering a fresh perspective and sometimes explaining things in a more accessible way. Well worth a read for aspiring JavaScript ninjas.

If you're using any modern browser (that rules out IE6 and IE7), you should
see a picture of a hot dog above.

But no such image file exists on my server—or on any other server. You're looking at a PNG image, but there's no PNG file anywhere.

How is that possible?

Right-click on the hot dog and view the image properties—in particular, note the image's src. You'll see a URI that begins with data:, followed by a very long string of gibberish.

That gibberish is the image data. Ordinary URIs simply point to data stored somewhere else. But URIs that begin with data: contain the data itself, represented as ASCII text. Instead of downloading an image file from somewhere on the Internet, the browser interprets the URI itself as an image file.

data: URIs can be used to embed any kind of data—images, HTML, JavaScript, PDF files, MP3s, anything—and you can use them wherever you'd ordinarily use a standard http: URI.

You can even use them in CSS files—and that's really the meat of this post. I'm going to show you how to embed image data in a stylesheet. It's actually quite simple.

This page contains the following inline style rule:

p.polka {
	background-image: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAYAAACNMs+9AAAABGdBTUEAALGPC/xhBQAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9YGARc5KB0XV+IAAAAddEVYdENvbW1lbnQAQ3JlYXRlZCB3aXRoIFRoZSBHSU1Q72QlbgAAAF1JREFUGNO9zL0NglAAxPEfdLTs4BZM4DIO4C7OwQg2JoQ9LE1exdlYvBBeZ7jqch9//q1uH4TLzw4d6+ErXMMcXuHWxId3KOETnnXXV6MJpcq2MLaI97CER3N0vr4MkhoXe0rZigAAAABJRU5ErkJggg==");
}

And here's a paragraph with the class polka:

Hi! I'm polka-dotted!

Why would you want to do this? The main advantage is speed. Ordinarily, the browser must download the stylesheet, parse it, and download each image separately. Even if the total payloads are the same, multiple HTTP requests are much slower than a single transfer. Embedding the image data in the stylesheet allows the browser to download everything in a single package.

This is the same motivation behind CSS spriting, which allows the browser to download a single image instead of many. The method illustrated here simply takes that principle to a logical (and arguably ridiculous) extreme, by eliminating the need for any additional downloads.

There are, naturally, a few limitations:

• data: URIs aren't supported in Internet Explorer 6 or 7. This renders them impractical for real-world use—unless you're working on an intranet, and can be sure that all users have a supporting browser.

• Internet Explorer 8 supports data:, but limits URIs to 32KB in length, and disallows most content types except for images and CSS (for security reasons).

• There's also maintenance to consider: new and updated images will have to be re-encoded and pasted into the stylesheet, and the next person who works on your site might look at your code and have no idea what to do with it.

• If you use the same images in multiple style rules, you'll end up with duplicate image data—which will increase load times. In this case, you're better off using regular URIs, pointing to real image files.

• This technique forces the browser to download all images on the first page view, rather than as they're needed. This could be a bug or a feature, depending on the type of site you're building.

So—at least until IE6 and IE7 go away—use of this method is limited to experimental projects and parlor tricks.

You can encode your own data: URIs with Ian Hickson's data: URI kitchen.

posts_nav_link() provides the simplest way to do this—it automatically displays either or both of the links, as needed. If you need more control over the markup, next_posts_link() and previous_posts_link() let you display them independently.

Typical usage goes something like this:

<div class="pager">
    <div class="pager-prev"><?php next_posts_link('&laquo; Older Entries'); ?></div>
    <div class="pager-next"><?php previous_posts_link('Newer Entries &raquo;'); ?></div>
</div>

But there's a problem here. What if a single page of results is being displayed? WordPress will render an empty pager:

<div class="pager">
    <div class="pager-prev"></div>
    <div class="pager-next"></div>
</div>

In my latest WordPress theme (the one you're looking at right now), this was throwing off my layout in some browsers. Despite enormous progress in browser standardization, there are still inconsistencies in the way browsers handle empty elements. Some will reserve vertical space for the element; some won't. Some will respect any margins that have been specified for the element; some won't.

Ideally, we simply wouldn't render a pager at all if one isn't needed.

Surprisingly, WordPress doesn't offer a simple way to determine whether the current query result spans multiple pages. There's is_paged(), but it always returns false for the first page of results, so it won't work.

Fortunately, $wp_query provides the information we need:

if ( $wp_query->found_posts > $wp_query->get('posts_per_page') ) {
    // show pager
}

This seems to work well so far!

There are still some layout quirks in Internet Explorer—I'm working on it.

Let me know what you think!

Honest feedback is always welcome—it helps me to provide a better site. Hope you find something you like!

Jared Spool explains how changing one button in a site's checkout process increased sales by $300 million per year. (He doesn't name the retailer in the article, but it starts with "A" and ends with "mazon.com".)