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".)

This isn't surprising—even if a site's designer is trained in the specialized discipline of typography (which is unlikely), the person who actually marks up the content (or pastes it into the content management system) probably isn't. But the fact remains that poor typography is one of the most common and most easily avoided blemishes on the web.

Am I being pedantic? You may think so—but I encourage you to hear me out and give it a try. I think your pages will read more easily, and look more professional and consistent. Even if readers aren't consciously aware of the typographical subtleties, they do increase a text's ability to communicate—that's why the conventions were devised in the first place.

Rather than reinventing the wheel, I'll simply point you to A List Apart's excellent article on the subject, with a few addenda of my own:

• As the ALA article explains, a hyphen is not an em-dash or an en-dash. The hyphen is also not a minus sign—there's a separate glyph for that. It's −.

  Similarly, the lowercase letter x is not a multiplication symbol—that's ×.

  These glyphs are designed to align well with numerals and with each other. Here's the vernacular version:

  9 + 3 - 4 x 2

  And here's the correct version:

  9 + 3 − 4 × 2

  Which one looks best to you?

  (If you're looking for the division symbol, that's ÷.)

• When marking up vulgar fractions (i.e., those in which the numerator and denominator are separated by a diagonal line, as in "1⁄2"), use the fraction slash (⁄) rather than the regular slash.

• If you're using Windows, you can type exotic characters by holding down Alt and typing the character's four-digit code on the keypad. For example, Alt+0151 produces an em-dash.

• If you're marking up foreign words (or English words, for that matter) which contain diacritics (commonly known as "accent marks"), then include the diacritics! They aren't just there for decoration—they're part of the word's spelling, and if you get them wrong, you've misspelled the word as surely as if you'd substituted one letter for another. It's "jalapeño", not "jalapeno"; "sauté", not "saute"; "fête", not "fete".

Granted, useful content and a solid technical foundation are more critical to a site's success than proper use of em-dashes—but every whole is the sum of a thousand details, and good typographical habits will become second nature after a short while.

Let's say you've finished building the HTML and the server-side validation code for your registration form, and you're now ready to write the code which stores the user's information (probably in a database). How should you handle the password?

The most obvious approach is to store it as just another column in the user table, with no special consideration. Many novice developers do exactly this—after all, you need access to the database to view the contents of the user table, so the passwords are protected, right?

But what happens when an attacker gains access to your database—for example, by guessing or intercepting your phpMyAdmin password? They have instant access to all of your user's passwords without even trying.

(Perhaps your application is trivial, and your users' accounts don't provide access to anything sensitive—who cares if an attacker gets their passwords? Well, many people use the same password for all of their accounts—email, bank accounts, and so forth. Our hypothetical attacker might not be able to do much damage on your site—but if the email addresses and passwords he just obtained allow him to gain access to other, more sensitive accounts, then you have a problem.)

Encrypting the password before storing it in the database is the obvious solution to this problem. Simply run it through your favorite encryption algorithm, and save the encrypted version; when the user logs in, just decrypt it to check the entered password.

This is also the wrong solution to the problem. An attacker who has access to your database probably has access to your file system, as well—which means they can easily find your encryption code and any keys it may use. Your encryption is useless in this case.

(Whatever you do, don't write your own home-brew encryption function, or run the password through a series of different encryption algorithms and arbitrary transformations, thinking this will make it more secure. It won't. In fact, this approach may leave telltale mathematical traces in the ciphertext which will make it easier for a skilled attacker to compromise your system. Leave the design of encryption algorithms to the experts.)

A better method is to hash the password, rather than encrypting it. Hashing is a form of one-way encryption: converting a password to a hash is easy, but reconstituting the password from the hash is mathematically impossible. Think of a trap door, or running a steak through a meat grinder—once something has gone through a hash function, it can't go back.

(Since the original string can't be reconstituted, hashing technically isn't encryption, no matter what anyone may tell you. I merely described it as such for illustrative purposes.)

But if we aren't storing the password in a way that can be decrypted, how can we check it when the user tries to log in?

Simple: hash the password entered on the login form, and compare that to the hashed password stored in the database. If the two hashes are the same, we know that the user entered the correct password.

(Incidentally, this is why many systems can't tell you your password when you forget it—they don't know your password. They only know its hash value. These systems typically handle forgotten passwords by asking you to choose a new one. Any system which is capable of providing your password on demand must be using some kind of reversible encryption—or, God forbid, storing it in plaintext—and should be considered less secure.)

PHP's md5() function is the standard hash function used for this purpose, but I prefer the more cryptographically robust sha1().

This is a lot better than our original system, and it's good enough for many applications. But our system still has a weakness.

Again, assume that an attacker has access to our database (and therefore our password hashes). Though he can't convert the hashes back into passwords, he knows that most people choose plain English words, or minor combinations and permutations thereof, for their passwords.

It's easy to generate a table of English words and their corresponding hashes (known as a rainbow table). With this in hand, an attacker simply has to compare your password hashes to the rainbow table until he finds a match. There are even pregenerated rainbow tables online.

(This is why good systems encourage you—or even force you—to choose complex passwords which don't appear in dictionaries. Generating a hash table based on an English dictionary is easy; generating one for every possible password-length string of ASCII characters is effectively impossible.)

For kicks, I once ran about 15,000 real-world password hashes (from a system I administrated) against the above-linked rainbow table. I was able to crack about two-thirds of them. Clearly, this is a serious vulnerability for any system which needs high security.

Fortunately, there's a simple and elegant solution: salt your passwords before hashing them, by concatenating them with a randomly generated string.

For example, let's say the user has chosen "ravens" as their password. If we simply hash this, it will be vulnerable to even the most basic rainbow attack.

So, instead, we'll generate a random string, four to ten characters long. (This is arbitrary; a few characters is sufficient.) This is known as the salt. (For convenience, I like to restrict my salts to printable ASCII characters.) Let's say our random-salt-generating function returns this:

^p]K~7

We prepend the salt to the password, and get:

^p]K~7ravens

Finally, we hash that string, and store the hash and the salt in the database. To check login passwords, we simply repeat the process (retrieving the original salt from the database, rather than generating it anew), and compare the hashes as before.

We've effectively turned a vulnerable, low-strength password into a strong one. Yes, our attacker can see the salt, and he could generate a rainbow table based on English words prefixed with that salt. But since the salt is different for every user, he'd have to generate a separate rainbow table for every user. The costs in time and storage space are prohibitive.

All of this may seem complex at first, but you're really only dealing with two database fields (the hash and the salt) and a couple of functions: one to generate a random salt, and one which accepts a plaintext password and a salt and computes the hash. Here's some sample code.

function generate_salt() {
    $salt = '';
    for ( $i = 0; $i < rand( 4, 10 ); $i++ ) {
        $salt .= chr( rand( 33, 126 ) );
    }
    return $salt;
}
 
function hash_password( $password, $salt ) {
    return sha1( $salt . $password );
}
 
// for user registration, do something like this
$password = getPasswordFromRegistrationForm();
$users_pw_salt = generate_salt();
$users_pw_hash = hash_password( $password, $users_pw_salt );
// store $users_pw_salt and $users_pw_hash; forget $password
 
// and for user login, do this
$users_pw_salt = getUsersPasswordSaltFromDatabase();
$users_pw_hash = getUsersPasswordHashFromDatabase();
$entered_password = getPasswordFromLoginForm();
if ( hash_password( $entered_password, $users_pw_salt ) === $users_pw_hash ) {
    // the correct password was entered
} else {
    // the password was incorrect
}

Is there something similar for iPhone? Not exactly, but we can achieve the same end:

<!--[if !IE]><!-->
	<link media="only screen and (max-device-width: 480px)" href="iphone.css" type="text/css" rel="stylesheet" />
<!--<![endif]-->

Some versions of IE will apply stylesheets regardless of the media attribute, so the conditional comments are here merely to tell IE not to use this code.

As for the value of the media attribute: not all browsers understand the "only" keyword; they will simply ignore this line. Of those that do understand it, the only one width a max-device-width of 480px is the iPhone.

(So I'm told. I'm taking all of this on faith. But it seems to work.)