50 lines
3.7 KiB
Plaintext
50 lines
3.7 KiB
Plaintext
A rant — Why are CSS designers so utterly freaking clueless?
|
|
<p>People who put absolute pixel sizes in CSS layouts should be lashed<br />
|
|
with knouts. I’ve tripped over this problem yet again while moving my<br />
|
|
blog; I’m using <a href='http://cafelog.com/'>b2</a>, and the default<br />
|
|
stylesheet shipped with it was obviously produced by some graphics<br />
|
|
designer who has failed to grasp the fact that there are lots of<br />
|
|
different display sizes and resolutions out there.</p>
|
|
<p>OK, for those of you who don’t see the problem here, it goes like this.<br />
|
|
Graphic designer composes his layout on a 1024×768 display. To make the<br />
|
|
spacing come out all pretty, he specifies a 10 or 11-pixel font which looks<br />
|
|
good on that 72-dot-per-inch display. Now I view it on my 1920×1440 display<br />
|
|
at over 120dpi resolution — and the font is 40% smaller and a hell of<br />
|
|
a strain to read. There are many other, related errors as well, like<br />
|
|
specifying absolute box or table widths when percentage of screen width<br />
|
|
would be more appropriate.</p>
|
|
<p>The basic error here is overcontrolling the layout rather than<br />
|
|
letting the user’s browser choose it in execution of the user’s<br />
|
|
preferences. Graphics designers are chronically prone to thinking of<br />
|
|
a browser as a device for delivering pixels, rather than information.<br />
|
|
But it doesn’t have to be this way — and, in fact, HTML isn’t<br />
|
|
supposed to be. You can make your CSS scale to the user’s chosen font<br />
|
|
size by specifying box dimensions in units of em, en and ex (which are<br />
|
|
evaluated relative to the parent box’s current font size) rather than<br />
|
|
pixels. But most CSS designers are apparently either too freaking<br />
|
|
incompetent to do this or just don’t give a rat’s ass about<br />
|
|
display-independence or the user’s preferences to begin with.</p>
|
|
<p>This sorry state of affairs is one of the better arguments for the<br />
|
|
proposition, widely shared among my peers, that graphics designers<br />
|
|
are basically a bunch of dope-smoking <a href='http://www.catb.org/esr/jargon/html/P/ponytail.html'>ponytailed</a><br />
|
|
dimwits who need to be smacked upside the head on a regular basis and<br />
|
|
not let anywhere near a software or web design without strict adult<br />
|
|
supervision by a cluebat-wielding programmer.</p>
|
|
<p>Another stupid graphic-designer stunt is changing the colors on<br />
|
|
visited and unvisited hotlinks away from the browser defaults (it’s especially bad when they’re mapped to the same color). What make this annoying is that it<br />
|
|
discards an important visual cue for web page users by making it less<br />
|
|
obvious where the hotlinks are. People who do this should be clubbed<br />
|
|
with a chair leg until they stop.</p>
|
|
<p>Sigh. Here’s the <a href='layout2b.css-orig'>default b2<br />
|
|
stylesheet</a> and here is the <a href='layout2b.css'>stylesheet I<br />
|
|
use</a>. Notice how much simpler mine is? The more you default<br />
|
|
rendering decisions to the browser like Ghod and Tim Berners-Lee<br />
|
|
intended, the more error-prone crap your stylesheets can omit, the<br />
|
|
faster your pages will render, and the better the user experience<br />
|
|
will be.</p>
|
|
<p>UPDATE: A reader tells me that part of this is the browser vendors’<br />
|
|
fault. It seems that on older browsers, only pixel sizes worked<br />
|
|
reliably. He says this has long since been fixed but the damage to<br />
|
|
CSS designers’ minds was already done. Another reader pointed me to a<br />
|
|
good rant on this topic by <a href='http://www.jwz.org/gruntle/design.html'>Jamie Zawinski</a>.</p>
|