3:24 pmOff
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.