Content, Form, Action

Including a very brief history of web design and a moral

There are three main components to any web project, in fact just about any new-/rich-/multi-media project: content, form, and action. The first two are basically what combination of text, imagery, audio, and maybe video comprise a project, and what it all looks like. These aspects are not so different from print-based graphic design, in that a designer often starts with a body of content and seeks to give the content some meaningful form. The third aspect, action, is perhaps more unique to screen-based design, at least in a technical way: books and posters don't generally come with actions, they're static, and each copy of a book is, with a few exceptions, identical to every other copy.

In the early days of new-/rich-/multi-media, when distributing a cd-rom, say, the hope was that every user of a cd would have more or less the same experience: everything required to create the experience was included on the cd, and no other software was necessary. And, in fact, the cd-rom application could do a lot to ensure that one user had as close to the ideal experience as the next: monitor resolutions can be changed, the colour depth can be changed, volume can be set, and so on.

The web is a little different: it used to be bad enough, trying to design a web site, when you didn't know what browser the user was using: was it Netscape, or Internet Explorer? Occasionally, you'd need to know if the user was running Windows, MacOS, Unix, Linux, or something else. The point being, you have no way of knowing how someone is viewing your site.

Initially, designers had very little control over what web sites looked like. There's a very good reason for this, which is that HTML, as originally defined, wasn't so much intended for visual design but rather document structure: what something looked like was considered to be less important than its structural integrity, to use a Star Trek-y phrase. So a simple document might look like this. You'll see that it doesn't look like any great shakes, but it's structure is clear: there's a header, a sub-header, a paragraph, another level of headline, and so on.

Eventually, some controls over what something looked like made their way into the HTML specification, and suddenly designers could make things look more or less like what they wanted. Now we got HTML that looked like this.

An improvement, surely? Well, yes and no. Designers got more control over the web's appearance, but that control came with a price: big, bloated web documents that were:

  1. slow to download;
  2. painful to change;
  3. hard to debug;
  4. unfriendly to alternative technologies (I'll come back to this in a sec);
  5. hard to make sense of

Let's take a look at the source code for the first example up there: 

<body>  
<h1>Content, Form, Action</h1>  
<h2>Including a very brief history of web design and a moral</h2>  
  
<p>  
There are three main components to any web project, in fact just about any 
new-/rich-/multi-media project: <em>content</em>, <em>form
</em>, and <em>action</em>. The first two are basically 
what combination of text, imagery, audio, and maybe video comprise a project, 
and what it all looks like. These aspects are not so different from 
print-based graphic design, in that a designer often starts with a body of 
content and seeks to give the content some meaningful form. The third aspect, 
action, is perhaps more unique to screen-based design, at least in a 
technical way: books and posters don't generally come with actions, they're 
static, and each copy of a book is, with a few <a 
href="http://store.yahoo.com/mcsweeneysbooks/lemon.html">exceptions</a>, 
identical to every other copy.  
</p>  
  
<h3>The Early Days of the Web</h3>  
  
<p>  
In the early days of new-/rich-/multi-media, when distributing a cd-rom, say, 
the hope was that every user of a cd would have more or less the same 
experience: everything required to create the experience was included on the 
cd, and no other software was necessary.  
</p>  
</body>

This sample requires 1220 characters of code and content. Of those, 1069 are for content, leaving just over 150 characters of code (one character of code for every seven characters of content).

This next example uses 1494 characters for the same content, but more code: 425 characters, or one character of code for every two and a half characters of content. And this is a reasonably well-put together example. 

<body bgcolor="#ffffff" link="#ff8204" alink="#339999" vlink="#999999" 
color="#2F3632">  
<font face="Trebuchet MS,Tahoma">  
<font size="6" color="#88bb00">Content, Form, Action</font><br>  
<font size="5" color="#339999">Including a very brief history of web 
design and a moral</font><br>  
  
<p>  
There are three main components to any web project, in fact just about any 
new-/rich-/multi-media project: <font color="#ff0000">content</font>, 
<font color="#ff0000">form</font>, and <font color="#ff0000">
action</font>. The first two are basically what combination of text, 
imagery, audio, and maybe video comprise a project, and what it all looks 
like. These aspects are not so different from print-based graphic design, 
in that a designer often starts with a body of content and seeks to give 
the content some meaningful form. The third aspect, action, is perhaps more 
unique to screen-based design, at least in a technical way: books and 
posters don't generally come with actions, they're static, and each copy of 
a book is, with a few <a href="http://store.yahoo.com/mcsweeneysbooks/
lemon.html">exceptions</a>, identical to every other copy.  
</p>  
  
<font size="4" color="#339999">The Early Days of the Web</font>
<br>  
  
<p>  
In the early days of new-/rich-/multi-media, when distributing a cd-rom, say, 
the hope was that every user of a cd would have more or less the same 
experience: everything required to create the experience was included on the 
cd, and no other software was necessary.  
</p>  
</body>

This approach leads to wild abuses, as in: 

<B>  
&nbsp;  
&nbsp;  
<A STYLE="color:#FFFFFF;text-decoration:none;" HREF="/isapi/gomscom.asp?
target=/catalog/default.asp?subid=22" TARGET="_top" 
onmouseover="this.style.color='#FFCC00';" onmouseout="this.style.color='#FFFFFF';">
All Products</A>&nbsp;  
&nbsp;  
<FONT COLOR="#FFFFFF">|</FONT>  
&nbsp;  
&nbsp;  
<A STYLE="color:#FFFFFF;text-decoration:none;" HREF="/support" 
TARGET="_top" onmouseover="this.style.color='#FFCC00';" 
onmouseout="this.style.color='#FFFFFF';">Support</A>&nbsp;  
&nbsp;  
<FONT COLOR="#FFFFFF">|</FONT>  
&nbsp;  
&nbsp;  
<A STYLE="color:#FFFFFF;text-decoration:none;" HREF="/isapi/gosearch.asp?
target=/us/default.asp" TARGET="_top" onmouseover="this.style.color='#FFCC00';" 
onmouseout="this.style.color='#FFFFFF';">Search</A>&nbsp;  
&nbsp;  
<FONT COLOR="#FFFFFF">|</FONT>  
&nbsp;  
&nbsp;  
<A STYLE="color:#FFFFFF;text-decoration:none;" HREF="/isapi/gomscom.asp?
target=/" TARGET="_top" onmouseover="this.style.color='#FFCC00';" 
onmouseout="this.style.color='#FFFFFF';">microsoft.com Home</A>&nbsp;  
&nbsp;  
</B>

(This example swiped from Microsoft on Monday, June 16, 2003; it uses 1012 characters, of which 46 are content and the remaining 966 are code, for a horrendous ratio of 21 characters of code for each character of content. In case you were wondering, the example will render like so:

    All Products    |     Support    |     Search    |     microsoft.com Home   

And, what's more, it could be simplified, using some simple style sheets, as so:

All Products | Support | Search | microsoft.com Home

This example uses 350 characters total, for the same amount of content, with a very simple style sheet: 

body{color:#fff}
a{font-weight:bold;
text-decoration:none;
padding-left:10px;
padding-right:10px;}
a:link{color:#fff}
a:hover{color:#fc0}

<a href="/isapi/gomscom.asp?target=/catalog/default.asp?subid=22" 
target="_top">All Products</a> | 
<a href="/support" target="_top">Support</a> |
 <a href="/isapi/gosearch.asp?target=/us/default.asp" 
target="_top">Search</a> | 
<a href="/isapi/gomscom.asp?target=/" target="_top">microsoft.com Home</a>

That's CSS in action for you.)

When I mentioned alternative technologies up there, I was referring to a range of devices that can make the web accessible in ways many of us don't think about: devices that can "read" a web document and translate it into Braille, for example, or speak the site aloud, or be used via a TTY rather than a personal computer. The problem is, when you look at the first example, it doesn't look good, but it's got structure. The second example also has structure, but only in the mind of the designer who put it together. If it was your job to update the site, say, would know what combinations of font sizes and colours to use when? And, more, should an alternative device view your web site, how will it interpret those font tags?

Using Lynx, a text-only web browser, we can get a quick sense of what things might look and function like in anything other than a desktop web browser:

This, the first example, works okay: the browser can't show a large font, but it does have a way of showing headers and paragraphs in a way that is pretty clear. And, in fact, this might resemble how web sites look on some cell phones and pdas.

This, the second example, is much less useful. Notice that because the browser can't interpret fonts, some of the key words (content, form, and action) don't get any emphasis at all. The tag in the first example, simply <em>, tells the browser that emphasis belongs on a word, but doesn't say what that emphasis should look like. Even Lynx can do something with that, in this case adding an underline.

This is Microsoft's web site, also on June 16, 2003. Not very useful, is it?

This last example, on the other hand, is Jeffrey Zeldman's site, and Zeldman is a name you should get to know, as he writes a lot of good stuff about the web and how it can be used. And you should be able to see that it actually looks okay, even in Lynx.

Now, why the heck is this important, you're asking? Is anyone going to surf the web using Lynx, and if they do, do they deserve anything other than a sucky experience? Well, maybe not, but today, the situation is even more interesting than it was: we can't assume the audience is even on a computer, really: are they using a PDA? A cell phone? A device as yet undeveloped, like a computer in a car or attached to the fridge?

And what does this have to do with the topic here, Content, Form, and Action?

I started out talking about how, when developing a cd-rom, everything was a single package, with the hope that everyone's experience would be pretty similar. But on the web, now, we have different browsers (Netscape, Internet Explorer, Mozilla, Opera, Phoenix, Safari, etc), different platforms of PCs (Windows, MacOS, Linux, Unix, etc), different devices (handhelds, cell phones, tablet computers), and each one works quite differently from the others.

On the web, then, you often use different tools and technology for each component:

(This list is based on one in Zeldman's Designing With Web Standards.)

It's possible on the web to completely separate content from form, and then attach them as required. (And, in fact, the difference between XHTML 1.0 and 1.1 is that for 1.1 validation, all physical appearance descriptions must be removed from the content, and handled via style sheets.) For example, let's look at that first HTML document again, with one small change: 

<style type="text/css">@import url("http://www.homemadeparachute.com/courses/css/edu-print.css");</style>  
<body>  
<h1>Content, Form, Action</h1>  
<h2>Including a very brief history of web design and a moral</h2>  
  
<p>  
There are three main components to any web project, in fact just about any 
new-/rich-/multi-media project: <em>content</em>, 
<em>form</em>, and <em>action</em>. The first two 
are basically what combination of text, imagery, audio, and maybe video 
comprise a project, and what it all looks like. These aspects are not so 
different from print-based graphic design, in that a designer often starts 
with a body of content and seeks to give the content some meaningful form. 
The third aspect, action, is perhaps more unique to screen-based design, 
at least in a technical way: books and posters don't generally come with 
actions, they're static, and each copy of a book is, with a few <a 
href="http://store.yahoo.com/mcsweeneysbooks/lemon.html">
exceptions</a>, identical to every other copy.  
</p>  
  
<h3>The Early Days of the Web</h3>  
  
<p>  
In the early days of new-/rich-/multi-media, when distributing a cd-rom, say, 
the hope was that every user of a cd would have more or less the same 
experience: everything required to create the experience was included on the 
cd, and no other software was necessary.  
</p>  
</body>

Take a look at it now: looks okay, doesn't it? There are no tags within the content that tell the browser what something should look like; those commands are embedded in a Cascading Style Sheet which is external to the document in question.

Moreover, with another couple of small tweaks, again not touching the actual content, I can make the document look like one thing on screen and like something else in print, very useful if you want to design a site that looks good on screen but prints cleanly too.

(Note: you could print the above example, if you wanted to, or take a look at this, which is a mock-up of what the screen would print like.)

If I were designing a site for use on handhelds or other devices, I can send a different style sheet, or set of formal descriptions, based on the device, thus keeping my content free and clear.

There are other advantages here, too: because my content is one entity, and the form is another, I can mix and match different forms with my content. I could add a style sheet switcher, allowing the user to choose a style that they're comfortable with, allowing them to select something that works with their eyesight. Or I might get bored with how my sight looks, and decide that I want to redesign the whole thing: all I need to do is change one external style sheet, and the whole site gets updated.

The Document Object Model

The DOM is one of the more abstract notions in web design, because it encompasses a number of things and their relationships. One way to think of the DOM is to see it as the interactive component of the web, the dynamism that can make the web not just a rich but a useful experience.

Class

Assuming you've already played with Cascading Style Sheets, you've seen terms like "class", as in 

<div class="codeSample">

A class, in this case, means that a definition for that class has been defined up in the style sheet, and maybe looks something like this: 

.codeSample{font-family:Courier,Monaco,monospace;
color:#000;
font-weight:normal}

The class can be used over and over again, and indeed that's the magic of CSS.

Id

Another way to structure a document, though, is by using id, which, like class, can determine what something should look like; unlike class, id can be used once and only once per document: id is a unique identifier which the DOM can use to act on a document.

For example, here is an element which is currently invisible:

Cowboy Wally

Because the invisible element has a unique id, we can use the DOM to change its invisible property:

show element | hide element

The code for this is quite simple: 

<p id="cowboy" class="printOnly"><img src="http://www.kylebaker.com/
www/multi/content2/wallychair.jpg" alt="Cowboy Wally" />
</p>

<p>
<a href="#" onclick="document.getElementById('cowboy').style.display='block';
return false;">show element</a> <a href="#" 
onclick="document.getElementById('cowboy').style.display='none';return false;">
hide element</a>
</p>

Having given the element an id ("cowboy"), we create a link which doesn't go anywhere (hence the "#" address in the href), but it does do something, attached to the onclick, which is a DOM event. On that click, we use another DOM function, getElementById(), and dynamically set the style of the element to have a display of block, thus showing the element. To hide the image again, all we need to do is set the style's display to none.

You could do more than just set the display, of course; you could set almost any property of an element that you could set via style sheets. You could attach events to things that aren't necessarily links, as in:

There are three main components to any web project, in fact just about any new-/rich-/multi-media project: content, form, and action. The first two are basically what combination of text, imagery, audio, and maybe video comprise a project, and what it all looks like. These aspects are not so different from print-based graphic design, in that a designer often starts with a body of content and seeks to give the content some meaningful form. The third aspect, action, is perhaps more unique to screen-based design, at least in a technical way: books and posters don't generally come with actions, they're static, and each copy of a book is, with a few exceptions, identical to every other copy.

This example uses the DOM to resize text when a user rolls over the paragraph. 

<p id="smallPara" style="font-size:4px" 
onmouseover="document.getElementById('smallPara').style.fontSize='12px';return false;" 
onmouseout="document.getElementById('smallPara').style.fontSize='4px';return false;">

This is just the briefest introduction to the DOM, just enough to hopefully explain the concept. It is definitely worth exploring further. A great place to read more about the DOM is A List Apart's series by J. David Eisenberg.