XML.com 
 Published on XML.com http://www.xml.com/pub/a/w3j/s1.people.html
See this if you're having trouble printing code examples

 

The Web is Ruined and I Ruined it
By David Siegel
October 02, 1997

The Web Is Ruined
and I ruined it

David Siegel

Every so often, dredging through the muck and mire of hopeless self-promotion and autodidacticism saturating the World Wide Web, one encounters an exotic specimen: the Web Head who truly merits it. David Siegel is not merely a self-proclaimed "HTML Terrorist," he has been so anointed by knowledgeable and right-thinking SGML/XML purists everywhere.

This article first appeared in Web Review in the depths of the Tag Wars. It describes how proper separation of structure (HTML), style (CSS), and semantics (XML) make content more compelling and design more effective. Visit David's sites at http://www.verso.com and http://www.dsiegel.com. [Ed]

The Roots of HTML Terrorism

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?

I ruined the Web by mixing chocolate and peanut butter so they could never become unmixed. I committed the hangable offense of mixing structure with presentation, and in HTML and SGML circles, that's a big no-no. The reason the HTML purists never carried out their threats is not that they're against violence, it's that they know that if they kill me, someone else will rise to take my place. It seems that structure and presentation have been mixed forever, and the Web is in the fast lane of the road to Hell. Fortunately, nothing on the Web is what it seems, and "forever" lasts only about six months.

Structure versus Layout

First things first: Structure is markup. Markup is structure. To mark up a document is to describe its structure using metadata, also known as tags. Tags were never meant to denote images or frames. Tags are meant to describe contents, not presentation. For example, the <P> tag denotes a paragraph (originally, HTML required a closing p-tag, </P>, but most browsers ignored it, so it fell out of use). A tag would denote something as a recipe, a movie review, a book title, a product description, a grade, a headline, a bowling score, etc. Imagine all the things that go into a newspaper. Properly tagged, you could apply a layout engine, using a set of lay out rules, to layout an entire newspaper automatically. Not surprisingly, this kind of application is exactly where SGML, the grandfather of HTML, came from.

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? Are they that extreme, those HTML extremists er, I mean, purists?

Let's take another example. A few sentences earlier, I wrote "they would not be part of the document" in italics. Remember that? Did I mean italics? Or did I really mean emphasis! [italics mine] Oh, yeah, that's what I meant, but I'm used to hitting the <I> key, not the <EM> key. Wow. Are they that extreme, those HTML extremists er, I mean, purists? Yes, they are that extreme. They can't believe everyone is using <I> for italics when they really mean <EM>, for emphasis.

The Roots of HTML

Let's look at the sheer beauty of this argument for a second. Separate all your content from its descriptive data (metadata, or markup), and the world suddenly gets interesting. You can see right through newspapers to the stock pages. You can compare movie reviews among 372 newspapers at once. You can search for Marx and find Karl, not Groucho, simply by filtering for the <PROMINENTSOCIALIST CLASS=MANIFESTOWRITER> tag.

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 Ph.D. 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.

Voilà! 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

Just after Tim did his thing, a kid named Marc Andreessen came up with the idea of the <IMG> tag, and the Web was both born and destroyed at that moment. You see, Marc is the founding father of the HTML Terrorist Guild, which now numbers in the thousands. As inventor of the <BLINK> tag, Marc has done as much damage as I have with less effort. All I did was take Marc's <IMG> tag a step further, to use single-pixel GIFs to help lay out a Web page. Seen from the perspectives of the SGML crowd, this is about as far away from the beauty of the original argument as one can get.

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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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

Here in the spring of 1997, I still have to use what works. My clients want to win on the Web, so we employ the method used by more political strategists: Image. We use great-looking sites and compelling experiences to create equity on the Web for our clients. Example: The coming bookstore wars. Amazon.com will have a lot of competition. All of them will have great selection, service, and advice on what to buy. The battle will be fought on design and editorial content, plus extra services that make people feel special. This has nothing to do with "information," but everything to do with attracting and keeping customers. How much information does Nike give out about its products? Not a lot. On the commercial side of the Web, design can make millions of dollars of difference.

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 http://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 Word's 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.

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.

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

One of the central questions surrounding the use of style sheets is: Who gets the final say over the look of a document? A small percentage of the readership is colorblind, another group prefers larger type, and others have special viewing requirements. Then there are alternative surfing environments like Web phones, WebTV, and Web dishwashers. Each has its own special browser and its own limitations. Aside from that, issues of available typefaces, available colors, monitor size, and other parameters affect the average surfer every day. Should there only be one way to view a Web page?

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

Because both Marc Andreessen and I are HTML terrorists, we are jointly responsible for the mess. Yet here our roads diverge. While Marc and his pals have been slaving away deep in the Netscape laboratory to bring us such visions of beauty as the <SPACER> tag and the <MULTICOL> tag--and now a new set of <LAYER> tags--I am in the process of 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

You're not on the commercial side of the Web, you say? Then why complain? Stick with your human-genome site and put helical horizontal rules all over the place. Wait for the rest of us to catch up. When XML hits, you'll be able to say, "I told you so." Until then, don't expect many visitors. When we have better tools, we will use them. When HTML evolves to the point that we no longer need to do browser detection or dynamic page serving, we will do things simpler, and better. Until then, we're going to go through another round of hacks where we put everything into databases and serve pages from there. It won't help the search engines at all. It will cost millions of dollars. It will all be totally unnecessary. Don't look at me. Look at Netscape. They break the rules; I just do what needs to be done. If I have ruined the Web, I apologize. It was my intention all along. Many people like me have put design and content ahead of structure, and now we can see a light at the end of the tunnel. Netscape has blocked the way, but they may be coming around. Site designers unite. Fight for presentation and structure. If we win, our future will be so bright, we'll have to wear shades.

XML.com Copyright © 1998-2006 O'Reilly Media, Inc.