Down to Brass Tacks Let's cut the crap.

Another Bunch of Web Concepts

Following a previous post, I kept hearing a discouraging amount of misinformation regarding some web concepts, so I thought I'd do as I did before and add my two cents.

Maximum Image Dimensions and Page Size

Alright, we all agree that we want our website to load rather quickly, because we know people aren't going to wait more than a couple of seconds. We also don't want mischievous people to be able to do much with our images. We have to consider the browser size of the bulk of our visitors when determining the size of our website, because we don't want to force them to scroll to see the whole thing.

These are all laudable objectives — I couldn't really disagree with them, in principle.

But 100-120 KB per page at most? 500-600 pixels wide images at most? That, I'm sorry, is based on egregiously outdated standards. Just so you don't have to take my word for it, I visited a bunch of photographers' web sites (they all happen to have blogs I follow) and looked at how large their images were — not the home page image, I mean the average image they present in their portfolio. You'll likely recognize these guys' name — I think they know what they are doing and/or have been professionally counselled.

The smallest images I found were those on Chris Orwig's site, and they were 693 pixels wide. Here's the rest of the random sample I visited:

• Joe McNally, 778 pixels wide
• Zack Arias, 804 pixels wide
• James Rubio, 819 pixels wide
• Drew Gardner, 826 pixels wide
• Chase Jarvis, 920 pixels wide
• Tim Tadder, 940 pixels wide
• Vincent Laforet, 1024 pixels wide
• Joey L, 1064 pixels wide
• Finn O'Hara, 1278 pixels wide

Wait, what? 1278 pixels wide? That's just the image, not even the website itself.

Do you have an idea what a single portfolio section of a site presenting such good quality imagery must weigh? A lot more than 120 KB. Did I have to wait an eternity to see the images, so much so that I thought I should give up and go to another site? Not at all. Do these guys really worry about their images getting stolen? Puh-lease.

I think I rest my case.

More on Image File Formats

Okay, so I'd already covered the key points in my previous post, but let's add some more information.

The idea that the PNG format came from PCs and never really caught on on Macs is simply baseless. The main reasons the PNG format was created were to improve upon the limited GIF format and to get rid of licencing issues (since GIF was patented by CompuServe). If anything, the Linux/free-software/open-source community (which was later, even before the OS X transition, largely embraced/encouraged/supported by Apple) did more for the format than the Microsoft-riddled make-everything-proprietary PCs. Indeed, Internet Explorer only recently got the memo that PNGs had an alpha channel, which is likely the main reason the format couldn't fully be exploited in the first place, hindering it's spread.

The idea that logos, which often use few basic colors, are prime candidates for the GIF format is only partially true. When you create shapes (be it in Photoshop or Illustrator) and convert them to raster images, new intermediate colors have to be interpolated to create seemingly smooth lines and curves — a process called anti-aliasing. The consequence is that even if you're only using few base colors when designing your logo, it might very well end up requiring more colors than can fit in an indexed color file format such as GIF. To be safe, go PNG, which is just as size-efficient, but not 8-bit palette limited.

The suggestion that you shouldn't embed color profiles in images to reduce file size is to be taken cautiously. If we all agree that images on the web should all be converted to the sRGB color space anyway (because we cannot presume color management will be available in the client's browser) and therefore don't decide to include the profile in our web images, well, it shouldn't really be a problem — if the profile is missing, every browser should presume sRGB, just as if color management was unavailable, so we're good. The risk, though, is that we some day forget that an image we export is for some other use (be it for a client, for a commercial printer that color manages, etc.) and then wonder why our images don't look as expected. Seriously guys, a color profile is about 2 KB — that's insignificant in comparison to the whole size of an image. Remove one step in your workflow and always embed color profiles, just in case; it's not going to hurt to do it, but it might if you don't.

The suggestion of creating a slideshow of photos using Photoshop's Animation functionality and exporting it as an animated GIF is preposterous even as a simple example. GIF is, as we know, a monstrously awful file format for photos, because it is 8-bit palette limited and will introduce screaming posterization or dithering. Furthermore, it will create huge file sizes because it is not designed to handle photos. Additionally, it won't allow (in any remotely economical fashion) transitions between images. Moreover, it won't allow any kind of control for the user (stop, pause, forward, back). Frankly, anything else would be a better idea — Javascript, Flash ... you name it.

Output Sharpening

I've already talked about the mistaken idea that the "Save for web" functionality would export smaller files. But what preparing images through Photoshop carelessly will also not do for you is screen output sharpening. Just save yourself the time and effort and error-prone procedure of doing that by hand the olde way and use something like Lightroom. (Or at least create yourself a batch action that also performs basic sharpening.)

Spacers

The dreaded "spacer.gif" (yes, this is the common name, not "single.gif") is a bronze-age-old hack. A trademark of poor code, of lazy development. There are other (better) ways to achieve what this shameless little bugger is doing.

If you don't mind the contempt you'll get for using it and still want to go ahead with the idea, keep in mind that images can be sized any way you want on a web page. This means that you should only create a single one of those darn things, one that is 1x1 pixel, and size it according to your needs on the page. For example, if you need a 600x400 empty placeholder, don't create a separate GIF file for the placeholder, just size your spacer pixel 600x400 at that location!

Alternate Text

You know the "alt" attribute of images? The idea behind that has absolutely nothing to do with search engines. Yes, of course, search engines will use whatever additional data at their disposal to enrich their databases and, hopefully, provide more accurate results. But that was not the motivation behind the "alt" attribute (which is required in strict versions of HTML).

The name says it: it is an alternative to the image, in case the image cannot be loaded or otherwise consumed. If the image is missing or there is any kind of problem, instead of showing the image, the browser will simply display the alternate text. If a blind person visits your website, not being able to see the images, their text-to-speech software will read the alternate text aloud. Therefore, the alternate text should be descriptive of what the viewer cannot see, not just a useless generic name like "image"!

Also, if you're using a spacer pixel (goodness forbid), you should include an empty alternate text (alt=""), otherwise if the text were to be called upon, it could break your design.

General notes on using CSS

CSS is fundamentally based on the idea of economy: the more global and the less specific the better.

What this means is that if you're going to be using, say, the "Verdana" font everywhere on your site,

• Proper CSS would call for defining "Verdana" only once as the font-family for everything in a single, global declaration. No need to mention it anywhere else, since this global declaration takes care of it all.
• Very bad CSS would call for redefining endless times "Verdana" as the font-family in each and every class you create. This not only means puke-inducingly redundant declarations, but also means that if you change your mind about the font used on your site, you'll have to go through every single darned class you've created and modify it. That's just about as far as you can get from the point of using CSS in the first place.

If you're going to use a property "everywhere, but", define a property in a global declaration (probably in the <body> tag or such an overarching location), then make amendments at very specific locations where the rules don't apply. This will dramatically reduce/simplify/tidy your CSS.

On the other hand, if you're going to use a property at a decidedly very specific location, don't define it at a global location, as it will affect every other use of the related tag/class. For example, I cannot see, for the life of me, any good reason to globally add a right padding to every friggin' link on the site if all you want to do is separate items in your footer. By doing this, you'll risk looking perplexed in front of 20 people when you won't understand why your thumbnails don't line up in their cells. Chances are that most links on your site are not going to benefit from a seemingly arbitrary padding on the right, even if some very specific ones might.

While I'm on the topic of padding a link... "Padding" is space inside an element, while "margin" is space outside an element. What this means, in the case of a link, is that even if the two properties would have the seemingly visually identical effect, the padding would make the link itself larger, while the margin would make the space next to the link larger. That is important, because if you're using padding on a link (goodness forbid), the "padded" section of the link would be active (clickable) as well:

Notice how empty space is active (bad!)

That's just wrong. The appropriate property to define, in that case, would rather be a margin.

Redefining Links with CSS

Alright, you want to redefine links (the <a> tag) so that they all look the same, except for the "hover" variant. So you're going to spend a couple of minutes duplicating your half-dozen properties four times in all of these variants so that they are all the same, except for the "hover" which will have a slight difference.

Since you've been reading what I said about global versus specific, you know that's no good. Instead of duplicating every-compound-thing from a:link to a:visited and to a:hover and to a:active (phew!), just redefine the <a> tag itself, once! Boom: all the links will share a set of properties defined globally. Then add only the differences you want to the "hover" variant. You're done. That takes less time and is more economic. Especially if you want to make a slight change afterwards — you won't have to make that change four times.

Lastly, be careful when removing the underline from links. You may want to do it for aesthetics reasons, but good design calls for good usability, not just cuteness. Make sure, if you remove the underline, that links are still obviously links. The underline is such an established standard that you should think twice before you do that — or just do it where it doesn't break usability, such as in a menu where items are obviously selectable, while leaving the underline for links elsewhere in the text. Also, don't use underline on text that is not a link (used purposely here) — that's very misleading.

Notes on a Bunch of Web Concepts

I recently heard a distressing amount of inaccurate/flat-out-wrong little pieces of advice related to web development that I would like to comment on. (There were many, so I may have forgotten a couple of them...)

Meta Keywords

I'm sorry guys, but meta keywords are dead. They've been dead for so long that their rotting corpses are past the point of identification. They've been dead ever since Google came along and shook the search engine business by bringing about the idea that relevancy shouldn't be entrusted to the web page developers who define the keywords.

No, they are not entirely ignored, but you should pretty much act as though they were. The title and file name of your web pages are far more important than the contents of the meta keywords, for example.

XHTML Syntax

If you're using Dreamweaver CS4, by default, you're not actually building HTML files, but rather XHTML files — even if you haven't noticed (the file extension is the same).

It used to be that structure and presentation were both defined by HTML code, but for a long time now (say, a friggin' decade), for many good reasons, they have been separated: HTML is strictly used for structure, while CSS is used for presentation. This is one of the core ideas behind XHTML, which uses a more strict/restrictive syntax.

That being said, XHTML uses strictly lower cased tags, with a self-closing terminator when the tag is not a container (see other differences here). This means that <META> and <P></P> are flat out illegal — the proper syntax is <meta /> and <p></p>. If you're using some kind of deprecated meta tag builder off a page from the last century that generates pre-XHTML code, you'll have to clean it up before you can use it (which defies the purpose of the whole thing, methinks).

Also, <td align="left"> is another leftover from HTML and is illegal in proper XHTML (the "align" attribute defines the presentation, not the structure!) Let CSS handle that part with an appropriate syntax — something like <td style="text-align: left;">. You got that right: this means that Dreamweaver itself sometimes generates bad code when you use its formatting toolbar. (Are you beginning to see why many web developers prefer working directly in the code rather than letting WYSIWYG software f**k everything up?) The same applies to width, which should be specified in CSS, not in the XHTML code.

CSS Class Naming

Classes should have meaningful names based on what they mean for the places where they will be used, not based on what they will look like nor on which tag they will be used. For example, you shouldn't have classes that are named .thinborder, .largefont or .redtext, but rather something descriptive of the meaning of the class, such as .menu, .header or .important.

Also, keep in mind that classes can be applied to many different tags, so a class named .paragraphbig wouldn't make sense since you could just as well use that class on a <span> or a <td> tag, for example.

CSS Size Units

So far, you've likely been using the "px" unit when defining font sizes, line heights or margins, for example. "px" stands for "pixels", so whatever value you define using pixels is absolute. This means that if you changed the scale of a web page, items that were sized/positioned using pixels wouldn't move one bit and you'd have to recalculate everything to make them fit. This might be just what you want, if you're using a very precise design of a strictly defined size that you don't want wiggling in any way.

This is often what happens when you're a graphic designer asked to build a web page — you create a template in Photoshop, separate your elements using slices and produce a direct translation from those raster graphic elements to the web without asking competent web developers how they'd do it. Needless to say, there are different schools of thought regarding these practices, but I would tend to think that absolute sizing/positioning in pixels is very often not the best way to look at web design — it goes contrary to the whole open-based/flexible/accessible mission of the web.

Granted, some elements just have to be sized using pixels (raster graphics are not scalable, by definition), but many others should be allowed some leeway! You cannot entirely predict/control what size/behavior everybody else's web browser will adopt, so you should allow your design to be (at least partly) flexible. Also, for accessibility reasons, you should make it possible for other people to enlarge the font sizes of your web site without it crumbling to an unusable/unreadable piece of crap. Go take a look on W3C or Wikipedia, for example, and you'll see what I'm talking about — entirely flexible designs that keep working fine whatever happens to the scaling/font size/window size...

This is where relative size units come in. Say hello to "ex" and "em". I won't bother you with a lecture in typography, but let's just think of 1 "ex" to be the height of the small-cased "x" and 1 "em" the height of the capital "M" of the current font (also, 2 ex = 1 em). Want to have more readable line spacing? Just define the line-height as "1.5em" rather than bother on calculating what pixel size should do it — that'll give you the result you want, whatever the size of the font you defined.

Anyway, look into relative sizes — especially for everything type-related.

Size and Resolution of a Gradient to Use as a Background

Whether you define your gradient image as 1x700 or 20x700 (unless you're using an utterly inappropriate file format — more on that below), it will not have a significant impact on the file size. Let me say this again: whether you define your image as 1x700 or 100000000x700 doesn't really matter, because each row in the image will use the same color, which means that the lossless compression will pretty much do away with it. Here, a gradient 2 pixels high and, horrors!, one 10 times larger, with a whopping 20 pixels high, saved as PNGs:

(3053 bytes)

(3139 bytes)

Like I said, insignificant. Let me also add, by the by, that 3 KB files are not a source for worry, in 2010. Seriously. Bandwidth is so much higher now that unsolicited videos frequently start playing inadvertently in advertisement boxes a the right of pages nowadays — do you have any idea how unbelievably larger a video is, compared to a 3 KB gradient?

And that "resolution" field in Photoshop? Meaningless. Resolution doesn't mean anything until you start talking about printing. Screen resolution is not up to you, because you cannot know what display will be used to view your web page. Just put 72 because that's the standard value we've come to use for screen graphics, but changing that to 300 or 5453982 wouldn't change *anything* to either the quality of the image or its file size: when it comes to displaying graphics on a computer monitor, the only thing that matters is the size in pixels!

Web Safe Colors

News flash: this isn't 1996 anymore!

It used to be the case that computer memory available for the display was so scarce that no more than 8 bits per pixel (not per channel, as you are familiar when working in Photoshop) was available. 8 bits per pixel (256 values total) is so little that you can't really describe much with it, so instead of using the 8 bits to define the colors themselves, they were only used to refer to a table containing 256 colors — that is what is known as using a palette, or a "color lookup table" (or the "Indexed color..." mode in Photoshop).

Color #1 might be a red, Color #2 might be a blue, etc. (the numbers themselves do not describe the color, just the position of the color in the palette). This means that not all colors were available, only a little subset of 256 preset colors in the palette. To be able to display a given color, it had to be available in the palette. But it gets worse, because even if a given color is available in the palette you are using, the next person might not be able to use that color because it is not available in her palette. And indeed that was the case: Windows didn't use the same palette as Mac OS, so you couldn't be sure that a given color would be available.

Long story short: "web safe" colors are a subset of 216 colors that were available both in Window's system palette and in Mac OS's system palette, so you could be sure that it could be displayed (fairly) correctly.

That was a long, long time ago. We're talking about more than a decade here — that's a ginormous number in computer speak. So what should you do? Well in 2010, that's fairly simple: ignore the whole web safe color business altogether! Seriously. I can hardly believe this needs to be said, so grotesquely obvious this should be to anyone even remotely familiar with these concepts.

This is especially ridiculous when it comes to creating a gradient. Think about this for just a second: even if you did use a web safe color for the "end color" of your gradient, realize that every single other color in the gradient would not be web safe! What an utterly pointless exercise! Using web safe colors with the intent of creating a gradient is a completely nonsensical enterprise from the get go.

Using the "Save for Web" Feature

There was a time, a couple of generations of the Adobe Creative Suite ago, when it shipped with a product called "Image Ready". This whole application was discontinued and integrated in Photoshop through primarily its "Save for Web" feature.

What this tool does is it allows you to preview what an image will look like using different web image formats and compare results in terms of fidelity and file size. Instead of guessing what JPEG compression 8 looks like versus JPEG compression 6, and how significant the compromise will be in terms of image size, with the "Save for Web" feature you can find out right away. That's a very practical tool in that sense, because you can "optimize" your choice once you have the means to take an informed decision.

But one thing you have to understand is that whether you end up saving the file through "Save for Web" or through a simple "Save" command, the file size will be exactly the same, for the same given parameters. It just isn't true that "Save for Web" produces smaller files: it just allows you to determine what will be the optimal file format and parameters.

Web Image File Formats

There are three formats universally acceptable for raster (bitmap) images on the web: JPEG, GIF and PNG. Anything else is not guaranteed to be readable — that includes PICT, BMP, TIFF, etc. (There are also vector image file formats, such as SVG, but that's another discussion.) These three formats have very distinct capabilities/properties and should not be chosen randomly: there are situations for which each is more appropriate.

If you're exporting pictures, there's no question that the appropriate format is JPEG. JPEG is to images what MP3 is to music: it's a lossy algorithm that is based on human perception. It retains more information where it is more significant for our human eyes rather than trying to retain 100% technically accurate values, which is not the point when displaying small images on the web. You want to be able to cut on the file size in a way that is optimal for preserving what will allow other people to look at your images, even if it means you'll lose some fine detail (where it is less obvious to the eye).

If you're exporting graphics — geometric shapes and design elements such as logos that use simple shapes and/or few colors — you're likely better off with GIF or PNG. The main difference between the two is that GIF is limited to 256 distinct colors because it uses a color lookup table. If the image you export contains 256 colors or less, you can use GIF losslessly. If the image you export contains more than 256 colors, then use the PNG format which is also very efficient with these kinds of images. (I won't dwell on the topic of dithering...)

GIF also allows to produce animations (you should see the "kitsch" neon flashing in your head by now), but more importantly it allows to use a single "transparent" color — a device that is often useful in a design to make the graphics merge flawlessly with a background. PNG, in fact, is much more powerful in that sense because it allows using a full-fledged alpha channel — kind of like a mask in Photoshop, with variable levels of opacity — so you could do away with GIFs altogether in favor of PNG. The problem is that the alpha channel feature is improperly managed by significant web browsers (god forsaken Microsoft Internet Explorer 6), so you should avoid using the transparency feature of PNG files for web use (unless you want to get into annoying hackery to go around this limitation).

JPEG is absolutely not appropriate for simple graphical design elements, because of the presumption it works under and the compression artifacts it is likely to introduce. The little 2 pixels high gradient I showed you before? If saved in JPEG, it is not only less accurate than the PNG (which is lossless), but the file is actually also many times bigger!

PNG is absolutely not appropriate for pictures, not because it wouldn't retain the quality, but because losslessly compressing a picture is very inefficient. Lossless compression is more efficient with repeating patterns, which a picture is anything but, at pixel level.

GIF is even worse for pictures, because you'd have to use dithering to render a picture, which would be awful and bring back memories of the '90s. Wouldn't want that.