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.

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

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