sRGB calibration patches
lRGB calibration patches
gradients treated linearly in sRGB
gradients treated properly in sRGB
linear-math (incorrect) anti-aliasation
sRGB-aware anti-aliasation
| Vid's Personal Standards |
These days, the accepted standard size for images (especially photos) shared online is 640x480. This works well in most cases. (I'll spare you my rant about people who post uncompressed formats like BMP.) But what if you prefer to present your artwork or photos in a wide-screen format? Or what if you're actually sharing a screen capture from a wide-screen source? Do you settle for 640x360 just to fit it inside the 640x480 "box"?
I say this is unnecessary. If I have an image to share that is in a 16:9 wide-screen ratio (this ratio turns out to be well-suited to road photos) I will present it online at 736x414. Besides being an exact 16:9 ratio, this image size has nearly the same number of pixels as the "standard" 640x480, so the file size will be comparable. On top of that, an image of this size fits very neatly inside a web browser window on a screen resolution of 800x600, along with all those toolbars and scrollbars.
What color is halfway between black (0,0,0) and white? Most people would answer gray (128,128,128). It's a good answer, considering the number 128 is half of 255 (rounded up) and that grey (128,128,128) looks about halfway between black and white. But it's a wrong answer, because in the sRGB color space (standard RGB, intended to be the standard color space for exchange of graphics on the Internet) the RGB numbers don't translate linearly to the actual amount of energy in the respective parts of the spectrum, and because the human eye doesn't perceive brightness linearly. Actually, that's one of the reasons sRGB is non-linear: to match human perception. The problem is, it screws up color calculations that are done simply. Just about every computer program that does any kind of mixing or fading (such as translucent layers, or on the edges of anti-aliased text) just does a simple linear calculation, and that's not good enough for me.
My solution is to do nearly all of my work in an "lRGB" color space environment. That's a lower-case L for "linear." The red, green, and blue components are exactly the same as those defined for sRGB, but the numbers representing the brightness of those components are scaled linearly, wheras in sRGB, the numbers are curved with an exponent of 0.454545 (1/2.2). When I'm done creating my graphics, the last step is to convert to sRGB color space by applying a camma correction of 2.2. To make sure I'm not surprised by the results of this gamma correction, I set up a display gamma correction of 2.2 in my image editor when I work in lRGB, and set it back to 1 when I work in sRGB. (My windows display drivers are already calibrated to sRGB. If you don't have two different display gamma settings, you can combine them by simple multiplication. Beware of "digital vibrance" and other color enhancements that mess with colors on your screen.) As it turns out, gray (186,186,186) is halfway between black (0,0,0) and white (255,255,255).
First of all, if you want plenty of examples of what NOT to do with a website, read this article written in 1999 showcasing everything that web designers commonly did wrong back then. Unfortunately, most of these mistakes live on today.
Some people who only use Internet Explorer and never customize the appearance of anything might think that how you code an HTML document doesn't matter as long as it "looks right." They think that the <P> tag "inserts two line breaks." They think there's nothing wrong with creating headings with only the <FONT> tag. Well, they're wrong.
The right way to do things is to structure the document with proper heading tags <H1>, <H2>, and so forth, and use <P> tags when and only when marking up a paragraph in the grammatical sense. Why? Because these tags carry meaning, not just appearance. This meaning is apparent when an HTML document is read by a visually-impaired person using a "screen-reader" program. Such programs allow the user to navigate the page by headings and paragraphs, but only if the proper tags are present. The same goes for tables, and lists and stuff.
Okay, so now you might be wondering how to fine-tune the appearance of an HTML document without screwing up the underlying structure. You might not like the default way that web browsers format paragraphs and headings and everything. Well, that's where CSS comes in. With CSS, the appearance and style of virtually any HTML element can be controlled, without altering its abstract meaning. For example, I use CSS quite a bit on this website, to format paragraphs and headings and links and those nav-boxes on the left with the links in them. Even better, CSS rules can be applied to specific media. This way, a web page can look a certain way on a computer screen, but can have a different appearance when printed. In fact, the presentation of a document can be optimized for any of several media defined in CSS.
What color is text in an HTML document if the code doesn't specify a color? Usually it's black, but this isn't always true. The same goes for the background color, which is usually light grey or white, but isn't always. In fact, depending on the user's color scheme and web browser settings, the default text color might be something very light, and the background color something very dark. The only thing a web author can count on is that the default colors probably contrast each other.
Unfortunately, some web authors don't quite get this. They will specify a background color for their web page, (or part of it) usually something very light, and they just assume that the text will be black. But if a user's default colors have light text on a dark background, they will see light text on a light background when they visit that page, and the result is text that is very difficult to read. Sometimes this is the case for me, as I sometimes use a Windows color scheme that has light text on a black background. I've customized my browser a bit (through a user CSS file) to try to detect when the background is specified but not the text color (or vice versa) but it doesn't work in all situations. If a web page specifies backgrounds via CSS instead of HTML, I'm forced to change my color scheme to a more "normal" arrangement. There are also similar problems encountered when a page specifies text colors but not backgrounds.
The solution to this is simple, but unfortunately it rests on the shoulders of all web authors. Any web page that specifies a text color should also specify link colors and a background color (or image). Any web page that specifies a background color, either for the whole page or for part of it, should also specify text colors and link colors everywhere the background color is specified. My main Vid's Space page specifies all text, link, and background colors, via CSS. This page, on the other hand, does not specify any colors—at least, not for on-screen viewing. The choice of colors is left up to the web browser and, in some cases, the viewer's operating system color scheme.