Adam Bosworth recently gave a talk about simplicity in technology, and how it’s far more important to be simple and sloppy than complex and pure. For the most part I agree with him; my first draft of XFN and FOAF was, basically, “FOAF is complicated. XFN isn’t.” While that was a flip way to amuse the reviewers, it also summarizes the core reason I took to XFN when Tantek and Matt explained it to me. Making things easy is always preferable to making them hard. As RFC 1925 so correctly states, “In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away.”
There are two places where I’d like to take issue with Adam, however. (And I hope it’s not presumptuous of me to call him “Adam” instead of “Mr. Bosworth”.)
The first is the idea that the Web should never be more complicated than plain old HTML. Adam says: “I very much doubt that an HTML that had initially shipped as a clean layered set of content (XML, Layout rules – XSLT, and Formatting- CSS) would have had anything like the explosive uptake.” This is absolutely common sense. I think it’s also common sense that any truly popular and useful system starts out basic—’primitive’, if you like—and grows in complexity. The best such systems hide the complexity from the end user. Automobiles have gone from a few very basic controls (steering, acceleration, braking) to the mobile gadget factories we pilot today. I still don’t have to know how the engine works to drive one.
So I absolutely agree that HTML caught on because it was simple. It had to be, because there was nothing to shield us from the system’s innards. When the popular Web was getting started, I did my best to promote its use by writing a trilogy of HTML tutorials (1, 2, 3). My entire goal there was to make it easier for anyone to publish their own content. Want to publish your grandmother’s Apple Pan Dowdy recipe? More pictures of pets? Bring ’em on! They way I figured, if everyone published what they knew, the best information would slowly rise to the top by virtue of gathering more links. Years later, Google built an empire around the concept of the best information being the most heavily linked. Ah well, another fortune lost.
Even then, I did take the time to teach well-formed markup because I knew that malformed markup was likely to cause trouble. This wasn’t an elitist thing, or some sort of far-reaching clairvoyance: at the time, it was possible to break browsers with incorrect nesting of inline elements. So it only made sense to tell readers, “Hey, if you nest elements, make sure they actually nest instead of just closing them at random. Otherwise your page might not get displayed.” Eventually, browsers got more tolerant of sloppy markup, and those kinds of warnings weren’t really needed any longer.
So anyway, here we are ten-plus years later, and we’re still arguing about table layout and XHTML being lower-case and blah blah blah. In the first place, table-driven layout isn’t simple. It’s flexible and sloppy, but not simple. The vast majority of table-layout authors have never touched a tag in their lives. They’ve just told some tool “do this”, and it did it. They don’t care how. They shouldn’t have to care how. So whether the tool generates 50KB of table-and-spacer markup, or 15KB of semantic markup with another 5KB of CSS, is wholly irrelevant to the user. As it should be.
It is, however, relevant to those of us who ply the back end of the Web. I’m not going to go over the arguments now; you probably know them, and know how you feel. But my feeling has always been that once word processors stopped fighting over file formats, and got on to fighting over ease of use and features while all reading the same formats, that’s when word processing software took off. I feel the same about the Web.
Now, I’m kind of a fan of CSS. Have been for a while. I like it because it lets the design (largely) happen away from the markup, where changes are easier, and it allows all kinds of stuff that HTML layout never managed. (Two examples right off the top of my head: letter-spacing and border-style.) I also like JavaScript and the DOM—not because they’re pure, but because they do what they need to do. Inspired by the work of others, I put all those pieces together recently and created a lightweight slide show system. It isn’t perfect, and because there are DOM actions it doesn’t always tolerate sloppiness, but it’s pretty simple. Once editors exist to let people just point, click, and type slides (and I suspect that such editors may exist in the relatively near future), it will be even easier. And the underlying format will not matter to 95% of its users. Nor should it.
Anyway, this brings me round to the other thing I wanted to talk about. Early in the talk, Adam says:
…in one of the unintended ironies of software history, HTML was intended to be used as a way to provide a truly malleable plastic layout language which never would be bound by 2 dimensional limitations, ironic because hordes of CSS fanatics have been trying to bind it with straight jackets ever since, bad mouthing tables and generations of tools have been layering pixel precise 2 dimensional layout on top of it.
First off, I think that Tim Berners-Lee might have a slightly different perspective on what HTML was intended to do, but let’s skip that. The part I don’t get is the perception that “CSS fanatics have been trying to bind” HTML. Personally, I’ve been trying to free Web design from the limitations it’s long experienced. I’ve been working in that direction for years now. I won’t argue that the job is finished: far from it. But a big reason I’ve long been an advocate of using CSS is that it loosens the straightjacket, not tightens it. The work I did within the context of the CSS Working Group was intended to loosen the bonds even further.
Maybe that means I don’t meet Adam’s definition of a “CSS fanatic”, I don’t know. Maybe I’m not one of the “hordes” of jackbooted geeks, seeking to impose my tyrranical notions on the unwashed. Either way, this does bring me to the question I want to ask: where does this perception come from, that CSS is promoted a way to make the Web harder and HTML more difficult? I’m not trying to belittle the idea by asking; I’m genuinely curious, and a little dismayed. I know I’ve worked very hard to clearly describe what’s good and bad about CSS, just as I have about table-based design. I’ve put a lot of effort into helping people who want to learn CSS do so, and explaining to those who ask why I think using CSS is a good idea. Most of the other CSS advocates I know have done the same. What is it that we did or didn’t do that got across this idea of inflexibility, or intolerance, or just plain elitism?
Because when you get right down to it, I’m still all in favor of people putting their stuff up for the world to see. These days, I’m also in favor of making it easier for everyone else to see that stuff, and for tools to collect and analyze that stuff. Standards make that easier—CSS makes that easier, although not as a standalone savior, but as part of a mosaic. If someone as well-regarded and experienced as Adam Bosworth doesn’t see that, then I can’t help but feel there’s been a failure to communicate.
