The average reader — one not raised by wolves, or, worse, by rabid advocates of Standard Generalized Markup Language during the heyday of SGML — may not clearly understand the concepts of Semantics, Structure, Markup, Content, Style, Transformation, and Presentation. Heck, I'm not sure many of us did back then either, but we've had a few years to think about it.

When Web designers talk about how the concepts are related (or how and when they should be kept separate, or even what technologies actually implement them) things get especially confusing. And more's the pity, because these very concepts comprise the very foundation of the Web, past and future. So let's take it slow. We'll carefully introduce these ideas one at a time, so that we can put a stop to the endless butchery of the terminology and the confusion that results from same.

Most Web designers who have peeked at the source of their documents understand the most basic concept we will discuss in this article: markup . But we'll cover it anyway. You'll thank us later, as it will clarify the relationships markup has with the rest.

Tags, Elements, and Content

"Markup" is information that you add to a text document in order to delimit — contain, or define the borders of — certain content. If you want to indicate that some text within an outline or in an article should be treated as a heading, wrap it with <h1> or one of the other heading tags. The same goes for quotes, addresses, lists and list items, and more. The markup isn't part of the content, it just sits alongside, marking the content up into specific chunks. You can think of it as an overlay, like a transparent sheet showing political boundaries lying atop a picture of the Earth from orbit. The artificial boundaries change everything, and yet they don't really exist in the physical world.

By the way, if you want to infuriate people who hate it when you're right, make sure you know the difference between "tags" and "elements" — tags are the things you insert into a document, that start with "<" or "</" and end with ">" or "/>" and start with the name of the element, known as an "identifier", such as "blockquote" or "p". Of these, only "start tags" may contain attributes and values. But you already knew that.

The combination of the start tag, content (possibly including other tags) and end tag is known as an "element". Now, you, too, can annoy people at geek parties.

For extra credit, sneer at those who use the term "tag" when they mean "attribute". Sophisticates may wish to also use the versatile Russian term nekulturny , and act as one might if confronted by a leper. This is a field rife with opportunity for snobbery. Try to be kind, or at least correct. Let's move on.

Some elements, though not all, have semantic value. Put another way, they say something (to us, anyway) about the content they enclose, above and beyond merely how it should be displayed. More on that in a bit, we don't want to get ahead of ourselves.

By definition, in simple documents, anything that isn't markup is "content". Strip away all the markup, and you're left with the content the markup was supposed to delimit, surround, or contain. Just to make absolutely sure we're perfectly clear on this, we'll use an oft-repeated analogy to add to our map overlay example above.

From Scribblings to Stylesheets

Markup, in the world of the early printers, simply took the form of written instructions (usually scribbled in the margins of some paper containing proofread copy). The instructions told the typesetter how to lay out the corresponding copy. Typefaces, sizes, leading, and so on were the basic components of document markup back in the early days. Everything was destined for print, so there wasn't any need to get too abstract; just point out the headlines, set the margins, pick out a nice typeface, and you were golden.

As time went on, and printing evolved, the introduction of increased mechanization, specialization, more complex workflow and electronic presses led publishers to create abstractions from simple markup. Instead of specifying that a given chunk of text should be 32pt/36pt Helvetica Oblique, the writer would simply mark it as a headline, and the printer or typesetter would be given a stylesheet containing mappings between abstractions such as "headline" and the specific layout instructions to be used when setting the type for that section of the document.

So, when thought of in this way, it's obvious that the markup should be considered separate from the content. The tags are inserted to specify that the chunk of content it contains should receive a certain "presentation" when rendered by a browser, or spoken aloud by screen reader software. Alternately, they're there to allow software to search for content of a specific type, such as quotes or addresses.

This is a bit more complex in modern documents, where some things we may be used to thinking of as "content", such as stylesheets or scripts, may actually be intended for consumption by the browser, not the end user.

Some of the stuff that is conveyed by markup (possibly even by attributes rather than using markup containers) is actually meta-information — information about the document that is, somewhat paradoxically, included in the document itself. Examples include the <meta> and <title> elements.

Finally, some markup is intended to produce certain behavior in the browser, such as some uses of <link> or the numerous form elements. But for our purposes, we'll restrict our definition of content to the stuff inside the <body> tags, and turn a blind eye to specialized, browser specific stuff like forms. With the powerful interactive capabilities of multimedia, and now, even CSS, behavior is becoming a far more important part of the Web, but we'll ignore it for now, and focus on the basics.

As if that weren't enough, some stuff we're used to thinking of as "content", such as images or Flash files, can only be embedded in a page by way of markup. But don't let that confuse you. The image files and Flash files and PDFs and so on are still "content", in a certain sense, they're just separate from the actual HTML document, and hence don't need to be marked up. Consider the case where external stylesheets containing <style> tags fail to work; this is because the externally referenced stylesheet is pure content.

Rest assured this all made sense once, and it's only due to the efforts of nice folks like Tim Berners-Lee and Marc Andreessen that we're using markup, instead of entity references or processing instructions or other, previously existing, mechanisms from SGML that did the same thing as the <img> tag, only better, and without confusing people like you. But that's all water under the bridge (or terabytes past the router) at this point.

Before we dive into presentation, let's talk about document structure and how it relates to the meaning of any given chunk of content.

Structure and Semantics

What is often lost to neophytes is a sense of the meaning, or "semantic value", any given tag, or element, lends to the content inside (This is largely due to their experience with the pathetically generic HTML tagset, which lacks all but the most basic semantics). Without the tags, the browser doesn't know where any one chunk of content starts or stops.

By the same token, some elements are simply there to provide document structure, which may also provide some contextual clues as to the semantics of those contents. List items outside of lists don't have much meaning (apart from any ephemeral presentation effects, such as bullets) and so they're not allowed to be outside of lists in valid HTML documents.

Of course, there are all the other obligatory elements that all HTML documents should have, such as <html> and <head> and <title> and <body>. Many of them can only be placed in the document in a certain order. <html> contains a <head> and a <body>, no more, no less. And in that order. And nothing else.

Because a lot of designers learned HTML by example, and often poor examples, rather than from the standpoint of structural markup and custom semantics, most have a poor understanding of how document structure and presentation are related. Because of the commonly used presentational elements (like <i>, <b>, and <font>), many designers habitually mix up a document's structure with the presentation they intend it to have in some specific browser. And I'm sure we've all seen documents with no head, two bodies, and all the banner-ad-launching scripts in a footer appended by some free hosting service, after the close <body> or <html> tag.

HTML, as markup languages go, is pretty simple. There are only a few dozen elements to learn, less than eighty all told in HTML 4.01 Strict and XHTML 1.0 Strict. By contrast, some markup languages, such as DocBook , can have several hundred or more. For example, compare HTML's elements for constructing definition lists with DocBook's elements for constructing glossaries.

HTML lets you construct a list of terms and definitions: <dl> <dt>term</dt> <dd>definition</dd> ... </dl>

DocBook lets you construct glossaries, containing entries, with terms, definitions, acronyms, other terms to refer to, abbreviations, and more: <!DOCTYPE glossary PUBLIC "-//OASIS//DTD DocBook V3.1//EN"> <glossary><title>example glossary</title> <GlossDiv><title>S</title> <GlossList> <GlossEntry ID="SGML" SortAs="SGML"> <GlossTerm>Standard Generalized Markup Language</GlossTerm> <Acronym>SGML</Acronym> <Abbrev>ISO 8879:1986</Abbrev> <GlossDef> <para>A meta-markup language, used to create markup languages such as DocBook.</para> <GlossSeeAlso OtherTerm="GML"> <GlossSeeAlso OtherTerm="XML"> </GlossDef> <GlossSee OtherTerm="markup"> </GlossEntry> ... </GlossList> </GlossDiv> </glossary>

You can see how much more richly structured and deeply meaningful the DocBook example is. In fact, you can use the rich DocBook tagset, otherwise known as a "vocabulary", to put an entire book into print, publish online, and more (and many industries already do). This is possible because the markup encodes the structure and meaning of the information in the content.

Technically, you could argue that the meaning is not really in the markup, that you need a mind or a script or other program embodying the meaning such that the meaning comes to life, but we only have a few hundred more words to get this article wrapped up, and the point is pretty pedantic. "Glosslist" is still more meaningful to us than "asdfghjkl", even though the computer may not care.

For our purposes, the markup lends meaning to the content that allows a script or other program to find it and, optionally, do something with it: produce PostScript for printing, render a Web page, speak it aloud, or even generate some other content (such as an index, or a body of statistics, or even an abstract art piece). The meaning may already have been latent in the content, and even perceptible to appropriately-educated humans, but computers are dumb beasts at best, so markup helps us make explicit what was, in some sense, already there implicitly.

To the untrained eye, this sort of implicit-meaning-made-explicit can look very redundant and even annoying. However, the more meaning can be made explicit, through the use of well-named and well-structured markup, the more powerful your documents become.

So, we've covered markup, content, structure, and to a certain extent, semantics. We've touched on the concept of presentation, but now let us dive in. The idea of presentation, and its separation from content and the rest, is perhaps the most widely misunderstood but one of the most important ideas in Web and document design.

Presentation, Style, and (maybe) Transformation

Over the years, most Web designers have become accustomed to thinking of presentation as a matter of whether a document displays the way they want it to in a given browser. Many brought these biases from the print world, where all manner of variables affect the one final presentation of a design — paper, inks, varnishes, die cuts, and more. Some simply learned as a result of endless cross-platform testing and debugging sessions, without the benefit of a theory or useful set of vocabulary.

Lacking such a vocabulary, it is difficult to talk about what is happening when one browser chooses a different mechanism for displaying a document, or when a visitor comes to the site with CSS or JavaScript (or, as in Navigator 4, both) disabled and receives another presentation entirely.

Some may think of presentation and style as the same thing, but style is merely one aspect of presentation. Transformation is another, more powerful, but less commonly used, aspect. Seeing as it has been touted as an enabling technology for the next generation Web, using technologies such as XSLT to operate on XML files, we'll discuss it briefly here.

Due to the nature of so-called "static" HTML, where you create a page and a server delivers it, which accounts for a large percentage of the pages on the Web, it is often difficult for Web designers to grasp the idea of "transformation".

Old-timey SGML folks, on the other hand, simply assumed that their task was to manage documents, which were sometimes nothing more than datasets, and that there would be another step between the document itself and the final product. This might be a filter that produced PostScript, an import and index mechanism that populated a database, or any of a number of different tools and end products, each tuned to make use of a subset of the data, and/or content, stored in the document.

A book might have embedded tags to show how a term should be indexed, but not contain the actual index, which would be generated at print time. A Supreme Court decision might have tags that support finely detailed indexing and searching, tuned to best suit a particular database or indexing toolkit. A Securities and Exchange Commission form might have entirely different tags and a number of different output formats.

The Web designer, who seldom has to produce for more than one target output format (or don't think they have to) can only think of their experiences with tools that carve up content into manageable chunks, such as content management systems, or with their attempts to make pages that work in powerful desktop graphical browsers as well as in handheld devices and terminal-based browsers. But these are not often transformations, per se, but merely different presentations, affected by styles and browser capabilities, not by an actual transformation of the original source document into something new.

There are several types of transformations one can perform on a document. One is structural, where some process (such as an XSLT template or other server-side process) reads in data (from a database or XML file) and wraps it in HTML, XML or other garb.

Another deals with reordering the components of a document, such as you might want to do to address the differing capabilities and purposes of terminal based browsers, screen readers, handhelds, and the like.

A third involves the selective display or delivery of document components, such as you might also want to do when targeting the same content at different devices or at audiences with varying degrees of access permission.

Presentation is therefore more a matter of target platform than simply a matter of style, and subsequently may be an issue of transformation, whether client- or server-side. For example, think of printer-friendly versions of online articles or "email this article" functionality, which take some subset of the rich melange of desktop markup and content and then strip off navigation, advertising, and other cruft not useful to someone holding a piece of paper or reading in an email client.

Depending on the platform, style may be associated with the results of a transformation, as well. You might use one stylesheet for one platform, another for print, and leave it out entirely for a handheld, and tune the settings contained in a stylesheet for those purposes, taking into account the results of any given transformation. Some sites use scripts to pick a stylesheet based on the capabilities of the browser, for example.

In sum, presentation is the net result of a combination of stylistic choices made by the designer, any transformations that may be done on the source document, and the capabilities of the target platform. So why do many argue for the importance of separating "content and structure from presentation," or any number of nonsensical variants on the theme?

Keep 'em Separated

The ugly truth is that it is often difficult and costly for simple sites to implement true separation of a document's structure (as implemented via markup) and content on the one hand, from a variety of presentations brought about by transformative technologies on the other. The tools are often difficult to understand, inefficient, and provide great examples of overengineering to meet a perceived need that is all too often barely understood by the owners of the content itself.

On the other hand, for documents that must by the nature of what they contain have a very long shelf life (such as parts and repair manuals for commercial airliners, Supreme Court decisions, SEC documents), there really isn't a choice in the matter. And as anyone who has worked on a site for more than a couple of years knows, some information becomes valuable over time, to the great surprise of those who initially published it on the Web.

For situations like these, where there is a definite need — or even a distinct possibility of one — for widespread, multiple-target versions of the same content, the content should be marked up in a way that preserves its rich meaning and structure. This should be done if only to make it possible to keep the content from becoming corrupted by the vagaries of any one specific platform. Think of all the font tags in a three year old annual report, or the tables used to implement a fin-de-siecle design, and then think of the effort required to extract them without ruining the content. Think also of the rich possibilities for semantically detailed structure (such as the DocBook glossary example above) and how they were degraded by the use of a limited tagset.

The situation isn't as bleak and futuristic as all that — support for Web standards in most recent browsers is making it possible, finally, to build sites that use styles to effect varying presentations across different audiences and platforms, as well as for different uses (such as stylesheets for print and audio). But this only works well if you don't bury your content in meaningless presentation-oriented markup, such as tables and font tags. This, in its simplest form, is the basic separation of structure and content from presentation.

Some would argue that such separation is impossible, or even undesirable, on the grounds that the end product must integrate the content and the designs used to present it. But they miss the point entirely — that to restrict oneself to one platform, one presentation, one corrupt document, is to deny that content to a wider audience, to whom the beauty of the design and the ease of use of navigation may be irrelevant.

Others would argue that the tools and technologies aren't there yet, that it isn't possible to strictly delineate content and structure from a given presentation while maintaining a useful and interesting result. They would argue that without XML support, semantically rich document structure isn't possible. Or that CSS, whose selectors may be dependent on the document's tagset, fouls separation of style from markup by tying them together.

They are usually interrupted, or ignored, by those who are already doing such things, making sites that are useful and interesting to their various audiences. Some may have a single stylesheet used across all pages, which is used to determine the presentation. An example of this is the recently redesigned Web Standards Project site, shown here with its default stylesheet and also with a specially tweaked stylesheet that uses a presentation that may be somewhat familiar to readers of this site.

The Web Standards Project

The "Webmonkey" Standards Project

Of course, this is just a contrived example, but see for yourself. The only difference between the two pages is the line that calls the stylesheet. The structure and content of the document is the same, but the presentation, implemented by way of a stylesheet, is radically different.

On sites that have been planned such that the entire presentation may be manipulated by way of styles, even more radical changes may result. Another demonstration of the power of stylesheet driven presentation may be seen if you print the WaSP site, as most modern browsers will try to use the provided "print" stylesheet instead of the default "screen" stylesheet.

Other sites may even use XML on the server side from which to generate gracefully degraded versions of their content for alternate platforms and devices.

There are some who dream of a Web in which those powerful vocabularies are the engine behind all pages; of a Web scanned by powerful and intelligent robots, which make searching incredibly precise; of a Web accessible from any device, anywhere, at any time, without the sad and pathetic experience of hearing the word "image" read a thousand times before a word of actual content is uttered. They dream, but it is not merely a dream but a rapidly approaching future. All to be made possible by the use of straightforward and disciplined distinctions between structured, semantically rich, content; and the platform- and device-specific transformations, styles and presentations that customize the experience to suit the user rather than the designer.