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

Simply include this code (and jQuery, of course) on your page, and assign the placeholder text as the title attribute of the control. Example:

<input type="text" name="keywords" title="Search" />

The script also assigns the class placeholder to the control when the placeholder text is present, so you can style it differently if you like (for example, you may wish to gray out the text).

The code:

/**
 * Unobtrusively set up placeholder behaviors on all text inputs for which
 * the title attribute has been set. The title text will be used as the
 * placeholder text.
 * @author Travis Miller
 * @link http://www.electrumdigital.com/
 */
$( function() {
 
    $("input[type=text][title]")
        .each( function() {
            showPlaceholder( $(this) ); // initialize each control on page load
        } )
        .blur( function() {
            showPlaceholder( $(this) );
        } )
        .focus( function() {
            var $input = $(this);
            if ( $input.val() === $input.attr("title") ) {
                $input.removeClass("placeholder");
                $input.val("");
            }
        } );
 
    function showPlaceholder( $input ) {
        var placeholderText = $input.attr("title");
        if ( $input.val() === "" || $input.val() === placeholderText ) {
            $input.addClass("placeholder");
            $input.val(placeholderText);
        }
    };
 
} );

(Most of these features are in "Last call for comments" status, so it's likely they'll make the final spec, but everything you're about to read is subject to change.)

• A couple of the new features are little more than UI sugar, but they're welcome nonetheless. The autofocus attribute does what it says on the tin. The placeholder attribute will display a hint value in a control—e.g., "you@example.com" in an email field—which will disappear when the control receives focus.

  No more crappy little scripts just to implement these simple UI behaviors—a few keystrokes, and you're done!

• The autocomplete attribute (already implemented by some browsers, including Firefox) will allow us to control whether the browser attempts autocompletion of a particular field. Disabling autocompletion is useful when you don't want a particular value (such as a bank customer's username) to be easily discoverable, or when dealing with a one-time entry (such as a CAPTCHA) where it makes little sense to remember the input value.

  Its natural partner is the list attribute, which will allow us to suggest possible values for the control. Presumably user agents will be free to implement this as type-ahead autocompletion (à la Google), as a combo box, or in any other way they see fit.

• There's a whole slew of new <input /> types, including calendars, color pickers, numbers, email addresses, and URLs, among others.

  This dovetails nicely with the new form validation model, which
  (in addition to enforcing syntax for values such as email addresses and URLs) will allow us to require a value, test it against an arbitrary regular expression, and restrict numeric values to a specified range and/or a specified granularity.

• Menus, of both the standard and context varieties.

  Individual menu items (and buttons, and other UI elements) will be associated with <command> elements. Presumably—I haven't thoroughly reviewed this part yet—triggering a menu item or other control will fire a DOM event on the associated command; client-side scripts can register event listeners on the command element, and respond without knowing or caring which element originally triggered the request.

In short, HTML's role as a document markup language is expanding to include interface markup as well. This is probably as it should be—there are few pages on the modern web (aside from W3C recommendations and documents repurposed from print) which the existing standards can describe without strain.

Many of the things we now code in JavaScript will be supported natively by browsers—we'll have to write less code, and users will get a faster, richer, more responsive, and more uniform experience. On the other hand, browsers will continue to grow in size and complexity—especially with the just-in-time JavaScript compilation featured in the latest generation, they're looking less and less like document readers, and more and more like runtime environments for applications.

There will undoubtedly be bugs to contend with in the first generation of HTML5 browsers, but hopefully browser makers have learned the lessons of IE6, and will at least attempt to comply with the spec. We still have a few years before the standard is finalized and widely supported, but (especially once CSS3 follows suit) it's going to offer some interesting possibilities.

<input type="submit" class="button" value="Save Changes" />

Because the <input /> element can represent many things other than a button—and because many browsers still don't support attribute selectors, such as input[type=button]—the author has added class="button" for the sole purpose of giving the stylesheet something to match on.

May I suggest a better way?

<button type="submit">Save Changes</button>

Now our stylesheet can simply use the selector button, and we don't have to add any extra classes to our markup. Overall, it makes for cleaner, more concise, and more semantically descriptive code.

That one isn't so bad, but this one is:

<input type="image" src="button.gif" alt="Save Changes" />

This is technically valid under XHTML 1.0 Transitional, but not under XHTML 1.0 Strict, and it's a bad idea in either case.

Why? Because it couples semantics with presentation, and that's exactly the sort of thing CSS exists to prevent. If the client later decides to replace button.gif with newbutton.jpg—or wants to change all image buttons to text buttons—you'll have to edit every page to make the change.

Instead, use this markup:

<button type="submit" class="submit">Save Changes</button>

...and use your favorite CSS image replacement technique to progressively enhance the document for graphical user agents. I typically use something like this:

button.submit {
    border: 0; /* to suppress default button styling */
    padding: 0; /* to suppress default button styling */
    background-image: url("button.gif");
    width: 128px;
    height: 24px;
    text-indent: -9999px; /* to hide the plain text */
    outline: 0; /* suppress the dotted hairline border */
}

Now you'll only have to edit one file—the stylesheet. Yes, we've re-introduced classes, but in this case it actually helps us separate concerns. You can define a base button style, and then define styles for button.submit, button.cancel, button.delete, button.help, and so on—each one pulling in the appropriate background-image and specifying the appropriate dimensions.