licentious radio

Monday, February 10, 2003
[11:15:00 PM]

Web Tribes.... The pixelists were using Quark Express before. The Flashists were using Director. Programmers gave us ASP/JSP and all that rot. The DTDists are the big winners -- they were irrelevant before, and now they're at the center of everything. The database folks also won big with the acceptance of content management systems. The "architects" scored with the n-tiered systems. The accessibility people were ascending until they lost their lawsuit, but time is probably on their side.

For a while, we had Wired magazine to tell us that it was *all* sexy. But now it seems like most of the shine is gone, and the masses are just stuck in cubicles with n-tiered Java (maybe with XSLT) instead of client-server C++. Fortunately, there's still a little fun discovering what all can be done with CSS, and it's complicated enough to not be easily accessible (compared to earlier versions of html).

[10:46:04 AM]
Missing from Shirky's article was the effect of search engines. Maybe not so many people read this weblog every day, but a steady stream reach a particular comment via Google and a few others -- on a wide variety of topics.

I'd expect that the inadequacy of search technology makes the distribution of search engine results much flatter than the distribution of weblog readership. Because you can't establish a context for your search, the results are skewed to the sequence of words. A Google search for the exact sequence of words that appears in your page title will put your page much higher up in the results for that particular search than you would get if your page were only ranked by links to it.

Between the Radio software that runs the site and the lame user interface that is my responsibility, few of the people who visit this site via search engines ever explore the site or even come back frequently. But I could do a lot more to build traffic if I wanted to.

[10:15:57 AM]
The dream of the pixel tribe is one page that works in all browsers, on all platforms. Ideally, you would have separate stylesheets for print and for smallscreen devices, and the basic html would work fine for any software that doesn't understand stylesheets at all.

The browsers that *do* understand CSS are supposed to render it exactly the same, though in practice you find hacks to target the various buggy implementations -- and you keep the hacks all in the same CSS file. "Sniffing" for browsers is uncool, because it's notoriously difficult to get right. By contrast, you just cut and paste the various hacks, and the whole tribe works together to figure out how you can exploit one browser's defects without breaking something in any other browser.

In practice, that's all fine, up until now. But in principle it's anti-web, and we are just reaching the point where it no longer works in practice.

The principle is that URLs are absolutely intended to be abstract. They don't need to map directly to a single file. You can have the server *choose* which file to send. Meanwhile, you win on the web by *pre-processing* as much as possible -- to cut down on the server cost. ASP/PHP/etc don't scale. If a page gets 100,000 hits in a day, why build it 100,000 times? For example, make a normal version of the page, and make a stripped-down version for handhelds -- cut most of the page junk and the big ads. Or, let the server choose between three or four stylesheets. The cost of the server *choosing* a file is trivial.

The reason the one-page-fits-all approach is about to break is the widening variety of common browsers. If your customer has a new $2,000 desktop with a 19-inch screen, you should have a user interface that makes appropriate use of Javascript and Flash, and all that screen real estate -- lots of ads and navigation, say. But if your customer has a new $1,000 handheld with a three-inch screen, you will want a low-tech interface. *And* you'll want to strip down the page -- not just change the page layout, and not just *hide* certain elements, but change what's on the page -- different navigation, different or no ads, etc.

Up until now, the pixel tribe has relied on the assumption that handhelds (etc.) don't know about stylesheets, and aren't widely used. But this is changing rapidly. The handheld computers designed for Microsoft's PocketPC are quite capable of running sophisticated web browsers, and there are several with excellent CSS support. More and more will incorporate mobile phones, handheld web browsing is just now becoming possible. This will require multiple versions of a page -- maybe not for your weblog, but for commerce and news sites, and for ad supported sites.

When you build several versions of the same document, you use some kind of automation. If you were going to build several versions of your CSS files, the *right* way to maintain them would be in a single source file with the branches marked up explicitly. You would edit the source file, and *test* the versions generated by some script.

For example:

<branch> <ns4>font-size: 12px</ns4> <allother>font-size: .9em</allother> </branch> line-height: 1.2;

This is more complicated than editing a regular CSS file, but probably easier to maintain than trying to cram all of your targeting into one file by hacks.

CSS has a built-in propensity for the code to become mind-bogglingly complex (the cascade), so you need discipline to keep things simple. The key to maintainable CSS is keeping the code as easy to understand as possible. Adding a layer of software between the code you edit and the code that the browser sees may help a lot.