Another must-read is the image optimization series from Stoyan Stefanov and Yahoo. Before reading those articles, I used PNG fixes indiscriminately, employed GIFs way too much, didn’t spend a whole lot of time thinking about the optimum image type when slicing a mockup, and certainly never thought of compressing images beyond Photoshop’s “save for web” feature. The first article in the series, The Importance of Images, along with the prevalence of Yahoo’s YSlow, and more recently Google’s Page Speed, made me realize just how much image optimization actually matters to page performance. I figured I would give you my take on the tips in the series, and thoughts on just how to handle difficult, common, transparency cases.
The Right Image Format
The image optimization series does an excellent job detailing which file format to use, and I suggest reading it (especially for the lossy, non-lossy comments), but here’s their summary:
- JPEG is the format for photos.
- GIF is the format for animations.
- PNG8 is the format for everything else — icons, buttons, backgrounds, graphs…you name it.
After implementing these strategies for a bunch of builds, here’s my take:
- JPEGs for photos or images with tons of colors
- PNG24 when you really need consistent alpha transparency
- PNG8 for everything else
The only difference here is that PNG24 definitely still has a place (oh, and really how often do you use animated GIFs?). The case they mention in which you have to use PNG24 (“When most of the image is semi-transparent”) is actually more common than they would leave you to believe. So how do you handle those cases?
Transparency and PNG Fixes
To handle transparent PNGs, do not use a JavaScript PNG fix. Instead, realize what those fixes do, and then actually apply the fix when and where you need it. The problem with PNG fixes in general is that they typically offer a blanket solution that affects every PNG on the site. You don’t want to be applying a alpha filter to a PNG8 that doesn’t have transparency, so there’s a lot of wasted effort. Not to mention the fact that these filters can be extremely taxing on the browser. There’s a simple CSS solution that can be added to an IE6-only stylesheet (assume #some-element already has a background applied):
#some-element {
background: none;
filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src='image.png', sizingMethod='crop');
}
That’s it! There’s also a VML fix, although the extra markup typically isn’t worth the better performance. Either way, the take-away is to apply the fix on a case by case basis, not with a blanket JavaScript add-on.
Compression
There’s a number of add-ons and/or tools online that will reduce the size of your images quickly and efficiently. The aforementioned YSlow and Google Page Speed are extremely easy to use if you have those add-ons. A new entrant is punypng, which touts its better performance over the Yahoo and Google offerings. Regardless, all tools offer bulk uploads, so after a site build, there’s no reason not to run your pages through these tools and update images that can be compressed.
If nothing else, I hope developers everywhere can remember a couple of things:
- Think about the optimal file format when saving an image
- Don’t use GIFs (unless they are animated… but c’mon)
- Don’t use a blanket PNG fix
I’ll be the first to admit that for the longest time I thought Arial, Times New Roman, and Verdana were the only fonts you could safely use on the web. When I was first getting starting in development, these were the only fonts sites used, and as such I never had reason to believe otherwise. Well after four or five years of working with some pretty talented designers, the importance of typography started to rub off. I’ve compiled a list of some of the most eye-opening typography-for-developers articles that I’ve read, mostly concerning the breadth of fonts that we can actually use in development now:
You know how every once in a while you’ll see a design that’s so well thought out and executed that it’s almost depressing, because you realize you probably never would have thought of it? Seems like this happens every time I see the newest and greatest Twitter visualization. Just to be sure, I went back and compiled a list of my favorites, all of which are simply stunning:
The HTML specification suggests “a mechanism for inserting quotation marks before and after a quotation delimited by BLOCKQUOTE in a manner appropriate to the current language context and the degree of nesting of quotations.” From a usability standpoint, it makes sense to indicate as clearly as possible that everything within a <blockquote> element is a quotation. To do so, I wanted to add quotation marks, clear indentation, and even a slightly different color to differentiate. Here’s what the result looks like in Firefox:
I finally got around to creating a WordPress theme, which was necessary because of some usability concerns I had with the previous theme. One of the major improvements I made was to implement what I call a “semi-fluid layout”, or one that scales to the size of your browser within pre-determined dimensions. In standards-compliant browsers, the page will now scale from 728 pixels to 900 pixels. I needed to declare a minimum width because at extremely small widths the content can break in unforeseen ways, and a maximum width because anything larger than 900 pixels made the main content column so wide it become difficult to read (shorter columns = better usability).