There's been a lot of talk in the newsgroups over the last 18 months about a guy named David Siegel, the Web's foremost HTML terrorist. Why do I get death threats in e-mail? Why do the so-called HTML "purists" hate my guts? And why did the W3C invite me to sit on the committees that shape HTML and style sheets? What kind of a snake pit is this? Have I really ruined the Web, and if so, what is my punishment?

This article takes several thoughts from my upcoming book, the sequel to Creating Killer Web Sites. It covers HTML and its evolution into a form of nerd Nirvana, and just possibly a desirable distraction for designers.

For the full story, simply go to www.dejanews.com and type in my name. Or go to the comp.infosystems.www.authoring.html newsgroup and watch the action first hand. Here's a bit of a response to the activity and a challenge to you, the reader, at the end...

Part 1.

Some people say I've ruined the Web, and to them it's true. Web pages can't be seen as easily by search engines and those with low-end machines have a hard time getting much out of my site. On my personal site, I don't even put ALT tags just to send a message to those surfing without images. My life is visual. I love museums. How would you like to visit the Louvre with images turned off?

Structure vs Layout

Layout is presentation. Presentation is layout. Apply one set of layout rules and get The New York Times. Apply another set and get The Village Voice. Notice I am not talking about content! I'm talking about layout. I'm writing this document in Microsoft Word. To tell you that The New York Times is a newspaper title, I've used the italic feature, as any good editor would. Now that you're reading it in HTML, someone has put it between <I> and </I> tags, so now you're seeing the title in italics, too. Blasphemy! How dare we use italics, when we mean <newspapertitle>The New York Times</newspapertitle>, don't we? If we had a <newspapertitle> tag, then people with 24x80 terminals in Zimbabwe would see "The New York Times" rather than The New York Times, because on a 24x80 terminal, you can't display italics. The browser itself adds the quote marks -- they would not be part of the document. In this case, the tag indicates meta-information, which the User Agent (also known as a browser) interprets, however, it can on the target display. Similarly, if this text were being spoken by a speaking browser for the blind (yes, there are some -- and no, they're not very good), the <newspapertitle> tag would be a signal to the program to pause and then emphasize the name of the paper. Gripping, isn't it?

The Roots of HTML

In a perfectly tagged world, no one needs a search engine at her own site. In a perfectly tagged world, the big search engines do all the work for us, by searching the Web and storing not only the data, but also the metadata. In a perfectly tagged world, we would standardize our tags, so that everyone would use the same exact tag to denote a <MOVIEREVIEW CLASS=HORROR>, or <RECIPE CLASS=VEGAN>. If one person decided to use a tag called <MOVIEREVIEW> and another used one called <FILMREVIEW>, the search engines would have a hard time keeping up with all the new tags (are you listening, Marc Andreessen?). Hence, the need for standardized markup (there I go again -- don't look at my source, okay?).

Go one step further and say what kind of a document you are reading -- a play, a newspaper, a PhD thesis, a recipe book, a journal -- and you soon need to generalize the language to include the document type, followed by the appropriate markup for that document type. Cookbooks contain recipes, report cards contain grades, plays contain dialogue, scene and action descriptions, and so forth. Standard tags for time sensitivity let visitors choose whether they want to see only the most recent content or see the last ten days' worth of material with every page they visit.

Voila! I've just performed a magic trick: Now we know what SGML is -- Standard Generalized Markup Language. It's a difficult concept, because the generalized part adds a layer of abstraction by first saying what species of document you have, then adds the markup appropriate for that species. Now that you understand it, you see where HTML came from. HTML is a fairly weak, underpowered set of markup tags for marking up hypertext physics papers. When Tim Berners-Lee talks about "inventing" the Web, he means that he came up with a few tags for writing physics papers and linking them together.

The Roots of HTML Terrorism

But it didn't stop there. I kept wanting to align my backgrounds and foregrounds, forcing readers to see pages my way, not the way they thought they wanted to see them.

Now let's return to the real world of the Web (not an oxymoron at all, in case the thought just crossed your mind). The Web got where it is in six easy steps:

Step one. The Framers of the Web mark up their papers on their NeXT machines and put them on the first Web servers, delighted to be avoiding FedEx charges to their limited particle-physics budgets. The <IMG> tag makes the Web visual, and products like PageMill reinforce the ugly-factor of first-generation sites.

Step two. I come along and start laying out pages visually, using HTML (admittedly, a markup language, not a page-description language) as it was never intended to be used. I pour narrative text into tables, completely hosing the idea that tables should be used for tabular material. My sites become popular. People start doing what I'm doing. I write a book explaining how to do it, and it becomes the Amazon.com number one best-selling book of 1996 in five months. The Web falls apart quickly. The search engines can't tell a picture of Dolly Parton from a picture of Dolly the sheep.

Step three. HTML changes so rapidly, and site maintenance becomes so difficult, that large sites start using databases to serve up their pages, separating the content from the HTML. Dynamic Web sites that cost $300,000 to build become the norm. Companies like Organic grow quickly, taking advantage of the market for database-driven sites. The search engines, which can't see inside databases, break even more.

Step four. Microsoft comes to the aid of the W3C and puts some muscle behind Cascading Style Sheets (CSS), for the sole reason that they are what Netscape is not doing. Also, as it turns out, the people in Microsoft's browser division saw that it was good to separate style from markup, and they made a good choice. Internet Explorer 3.0 ships with style-sheet capability. Few people write style sheets, but they are a good step forward.

Step five. NetObjects Fusion, a product based entirely on my principles (you can see my filenames in their code and I didn't get any NetObjects stock -- what is it they say about imitation and flattery?). The product takes a baby step toward becoming the first PageMaker of the Web. Databases detect which browser you're using and serve sites adjusted for all the different display bugs. Structurists see Fusion sites being paired with databases and prepare to eat the sleepy applesauce and lay down with purple shrouds over their heads.

Step six. Style sheets don't solve all layout problems, but they improve typography greatly. Netscape announces a whole bunch of new tags to keep people smoking their layout crack. Because Microsoft has aligned with the W3C, Netscape tries to reinvent Director by putting lots of "dynamic HTML" tags into their 4.0 browser. The design community isn't sure what to do.

Keep in mind that the purists are protecting some pretty fetid ground. Most of the content on the Web is garbage, and most of my content turns to garbage after some reasonably short period of time. Trying to find quality on the Web is like trying to find arable land in Antarctica. The Web is a visual medium -- not to design is to design. Personally, I'd rather leave the design up to professional designers than programmers, but hey -- that's me. It's easy to be proud of your Web site. It's another thing to have people say it was visually appealing and easy to find everything.

Back to Reality

Does that mean Amazon.com should use every new gizmo and tag Netscape provides? Does that mean we should suck up to the smarmy <LAYER> tag and leave the standards body behind? I hope not. I support the standards process. Right now, there is an interesting debate in the W3C over something called the OBJECT model. It promises to give us active, dynamic Web sites and still separate content from presentation. For some odd reason, Netscape is actually being quite helpful and conciliatory in this debate, and though we can't figure out why, we certainly see it as a good sign for designers.

I can't say that much about the OBJECT model yet, because there are a bunch of details to work out. Suffice to say it won't involve any new tags, because tags are for markup, not layout. It will involve the use of a special tag, called <DIV>, which we already use today in our work with style sheets. (View the source of www.highfive.com to see our current use of style sheets.) We expect both fifth-generation browsers to incorporate the still-unapproved OBJECT model within a year.

We are waiting for PNG, the Portable Network Graphics format, to replace GIF. Let's hope that by the end of the year most images on the Web are PNG, with several levels of transparency and a much richer set of extensions. It's been a political battle, but PNG is promising and it will come. Add PNG images to your sites -- visitors using Netscape Communicator will automatically download the PNG plug-in the first time they encounter one. Let's hope they encounter lots of them. Perhaps professional-quality image standards like LivePicture and Olivr will take us even further in our quest for low-bandwidth quality.

We are waiting for vector graphics like Flash. Flash images will be tiny. They will look great. They will be as close as you can get to PostScript without making a PDF.

We are waiting for something in between SGML and HTML. SGML is too general and too complicated for the Web. Instead, we need a junior version, and that's called XML. Just formulated in the fall of 1996, the ideas behind XML are good: To create a generalized markup language independent of presentation that works for most of the document types found on the Web. I'll talk about XML another time, but the early news is that Microsoft is interested and excited about taking HTML in this direction. In a few years, Microsoft Words' underlying data could be marked up in XML, but it's a bit far off to be making predictions like that (I just can't resist trying to tilt the playing field).

We will have to wait before the tools catch up. About two years ago, I said the first halfway decent tools would appear in late 1997. I may get lucky and be on track with that prediction. Then again, we may have to wait a while longer. HTML isn't PostScript. It's hard to build tools that don't suck on top of a set of standards being used in a giant tug-of-war between big companies with millions at stake. Until good tools exist, web designers will continue to be used as human shields in the browser wars, with our customers being the big losers as they pay us to make two separate versions of everything and serve HTML out of custom databases.

Part 2: Style Sheets: The Light at the End of the Tunnel

Let's take one thing at a time. If we're going to learn anything, it's that style sheets are the future and tag-based layout is the past. What can style sheets do? They can do a lot of typographic things, like set your margins, indents, drop caps, leading, and other niceties invented in the time of the Romans. No longer should we pour our text into tables, for I have led us through the desert for 40 years (seemed like it, anyway), and we have emerged in the promised land, where style sheets give us the margins we seek. Sure, we still have to use tables to lay out our pages, but in a year or so, we hope to give that up, too. Say goodbye to the single-pixel GIF! Use it only when necessary! Ban the kluges -- learn to use style sheets today!

Okay, maybe tomorrow.

Turns out that the Internet Explorer 3.0 version of style sheets is pretty different from the 4.0 version, and the Netscape Communicator version will likely have its differences. We will find the common presentational behavior of both 4.0 browsers and use that. Stay tuned. One thing you don't want to do is to commit style-sheet terrorism. Style-sheet terrorism is where you use style-sheet capabilities by brute force, mixing the style primitives right into your content, rather than separating the content from the description of the presentation. Look at Microsoft's Style Gallery. It's shameful. Look at both the code and with Netscape Navigator 3.0. What's going on? To get a drop-shadowed "3," they've used the actual number two times -- once dark and once light -- positioned on top of each other. Not only that, but the number itself is part of an ordered list -- the program should take care of the numbering automatically! The style sheet should describe the behavior of an ordered list in the absence of the list data. I repeat: There should be no use of style sheets to effect typography that is bound to the content. Style sheets must describe content that isn't there, then be applied to content that is. If the style sheet doesn't give the intended result, debug the style sheet, not the data.

When good ideas go bad: Style-sheet terrorism.

To be fair, the gallery was created last summer in a rush. The people hired to make it were just playing around. But they didn't understand the basic concept, and Microsoft let everyone see it as an example of how to use style sheets, mostly because it looks awful in Netscape. If you did it correctly, your pages would just look gray and dull in Netscape, rather than all screwed up, and that would reflect badly on Microsoft, hence the style-sheet terrorism.

The Big-Brother Issue

My answer is simple: The designer should be able to specify how the page looks under most conditions and give more (but perhaps not total) control to the viewer as a last resort. In other words, designers should be authoritarian, not dictatorial. Fortunately, that is roughly how style sheets work. Style sheets can cascade, and that has two meanings, so let me take them one at a time.

Style sheets can refer by name. A style sheet can include another style sheet simply by naming it, specifying its absolute or relative location on the Web. This lets us build a hierarchy of simple, middle, and more complex style sheets without reinventing the wheel every time we write one. As with Java, the lower-level libraries are just now being built (by no one, actually, but we hope someone starts working on them soon). Then we can write more complicated style sheets based on those and place them on public servers. All you'll have to do to use a Dave Siegel style sheet is include its name and location at the top of your file, and its full functionality will apply to your document. Is that going to make using style sheets easy? Yes. You won't have to write anything. You'll just find the style sheets you like and specify them by name.

Style sheets have the capability to degrade gracefully. Today, you can specify which fonts to use for which sections of a site, and if those fonts aren't available, you can specify a second and third choice, and so on. Style sheets go further. If a style sheet is well written, it will contain instructions for what happens when you see a Web page under optimal conditions (big screen, fast modem, lots of colors, etc.), then how it should look under suboptimal conditions (256 colors, 14-inch screen, slow modem), and also how it should look under lousy conditions (WebTV, Microsoft CE, black-and-white screen, etc.). There aren't three levels of cascade, there are as many as the designer can specify.

One of the most vexing things about this approach is that we still don't have standard ways of learning how big or colorful people's systems are, and this is a huge impediment to site designers. The W3C could have long ago specified ways for people to fill out a little profile in their browser, specifying, among other things, how many colors they have, how large their screen is, whether they have sound capability, etc. There are a lot of other Big-Brother issues surrounding profiles, but I'm a strong believer that people will benefit by giving sites a bit of information about themselves (demographics), their lifestyles (psychographics), and their viewing systems (technographics). If the Web is going to be free, it's a small price to pay for getting better service. And anyway, if you don't specify a profile, you don't get the benefit of it. No one would be forced to fill out a profile, but if most people did, it would help sites degrade properly.

Finally, style sheets take the correct stance that the viewer should, in the end, be able to specify her own style sheet for her own viewing. She should be able to set up her browser (User Agent) so it always overrides the designer's style sheets and substitutes her own. There should actually be levels of override. It should be fairly hard to completely throw out a designer's intended style sheet, but if she checks the box marked "Hey, I really really really want to use my own damn style sheet, okay?", then she should be able to get her way.

Turning in My Black Hat

I am leaning toward structure. The hacks I've espoused, especially the single-pixel GIF, and using frames and tables to do layout, are the duct tape of the web. They are the designer's finger in the dam, trying to keep the ugly gray sites where they belong -- at Yahoo, not in our portfolios. Several of the things I've mentioned here are part of doing it better.

Some day, the purists and I will see eye-to-eye, while Marc and company keep on tagging, with lame excuses like: "Our customers demand interim, tag-based solutions." Hogwash. When the browser manufacturers let us separate content from presentation, we will gladly comply, for the benefit of surfers everywhere. My personal priorities are that design drives the train, because to hold an audience, you need good content presented well. The best content poorly presented will lose to a better idea hidden by dull presentation (presidential elections aside).

XML promises to be the Alexandria (I won't say Xanadu) of our digital desert dreams. It will let us build great libraries simply by building our own sites. It will let the average person put together very sophisticated and powerful applications, simply by tagging everything properly so it fits into the larger schema of the Web. Style sheets and the OBJECT model will provide the layout capabilities to make it look good. Then, in that future, we will have databases only to do what databases do best: Search for and compare 283 possible ways to get from San Francisco to Denver on July 3 for the lowest fare, find the best combination of 40,000 products for a particular visitor, or to do banking transactions. In this future scenario, Web sites will be big, flat, and tagged full of standard-compliant meta-data descriptions. Then the webmaster will tend, or farm, this flat Web site, using automated content-management tools to help keep it all up to date. Meanwhile, the search engines will grow more powerful every day and the average site builder will be able to participate. Radical, yes. You decide who is extreme.

Light at the end of the tunnel

The Challenge

About the author:
David Siegel is a regular contributor to the High Five (www.highfive.com). He is a member of the W3C's Font, Style, and HTML committees. He is a founding member of Studio Verso, which designs and produces high-end web sites for demanding clients around the globe. Studio Verso most recently designed the W3C's "Made with Cascading Style Sheets" logo, soon to be seen on web pages everywhere. Several dog-eared copies of his book, "Creating Killer Web Sites," were found at the scene of the Heaven's Gate cult suicide. He consults with many companies and gives regular talks and workshops. His forthcoming book, on project management, is due out in July. For more information, visit his sites at www.verso.com and www.dsiegel.com.