Example 3-1 presents an ill-fated but not altogether uncommon attempt to create an information architecture for the New Car Reviews module. The problem in this example is that it uses HTML markup more to define the layout than to reveal the information architecture of the module.

<table>
   <thead>
      <tr>
         <th>
            <big>New Car Reviews</big>
         </th>
         <th>
            <small>
               <a href="http://...">The Car Connection</a>
            </small>
         </th>
      </tr>
   </thead>
   <tbody>
      <tr>
         <td colspan="2">
            <p>
               <b>2009 Honda Accord</b> <i>(from $21,905)</i>.
            </p>
            <a href="http://.../reviews/00001/">Read the review</a>
         </td>
      </tr>
      <tr>
         <td colspan="2">
            <p>
               <b>2009 Toyota Prius</b> <i>(from $22,000)</i>.
            </p>
            <a href="http://.../reviews/00002/">Read the review</a>
         </td>
      </tr>
      <tr>
         <td colspan="2">
            <p>
               <b>2009 Nissan Altima</b> <i>(from $19,900)</i>.
            </p>
            <a href="http://.../reviews/00003/">Read the review</a>
         </td>
      </tr>
      <tr>
         <td colspan="2">
            <form method="post" action="http://.../email/">
               <p>
                  Get our most recent reviews each month:
               </p>
               <small>Email</small><br />
               <input type="text" name="nwcreveml" value="" /><br />
               <p>
                  <input type="submit" name="nwcrevsub" value="Sign
                     Up" />
               </p>
            </form>
         </td>
      </tr>
   </tbody>
</table>

First, everything has been placed within a table to achieve a presentation in which some elements appear side by side while others appear above or below each other. In fact, the developer has gone to a lot of trouble to create a two-column table simply to left-justify “New Car Reviews” while right-justifying “The Car Connection” on the top line; all the other tr and td elements are redundant. Naturally, the columns in the th header have nothing to do with the “rows” underneath it; the table is being used simply for visual effect.

From a standpoint of information architecture, tables are for tabular data; we’ll look at better ways to achieve a side-by-side presentation in Chapter 4. The limitations of misusing table elements will bite you if the page has to be used for new purposes, such as for display on a mobile device or providing information in a web service.

Another problem is the heavy use of the purely presentational elements b, i, big, and small. These describe how we want things to appear, not what information the elements enclose. Markup like this is also often accompanied by HTML attributes such as width, and border that also serve only a presentational purpose (although I have avoided showing them here). The HTML standard has accumulated an astounding number of such attributes, but they have no place in large-scale HTML.

Example 3-2 presents a better attempt to reflect the information architecture for the New Car Reviews module.

<div id="nwcrev">
   <span class="head">
      New Car Reviews
   </span>
   <span class="name">
      <a href="http://...">The Car Connection</a>
   </span>
   <div class="list">
      <div class="item">
         <p>
            <strong>2009 Honda Accord</strong>
            <em>(from $21,905)</em>.
         </p>
         <a href="http://.../reviews/00001/">Read the review</a>
      </div>
      <div class="item">
         <p>
            <strong>2009 Toyota Prius</strong>
            <em>(from $22,000)</em>.
         </p>
         <a href="http://.../reviews/00002/">Read the review</a>
      </div>
      <div class="item">
         <p>
            <strong>2009 Nissan Altima</strong>
            <em>(from $19,900)</em>.
         </p>
         <a href="http://.../reviews/00003/">Read the review</a>
      </div>
   </div>
   <form method="post" action="http://.../email/">
      <p>
         Get our most recent reviews each month:
      </p>
      <span class="label">Email</span>
      <input type="text" id="nwcreveml" name="nwcreveml" value="" />
      <p class="action">
         <input type="submit" id="nwcrevsub" name="nwcrevsub" value=
            "Sign Up" />
      </p>
   </form>
</div>

First, we have replaced the various table-related elements with div and span elements. These immediately reveal a more systematic hierarchy that reflects the true relationship between the elements. In addition, we have added IDs and classes with good, semantic names that tell us a bit more about what the elements enclose. These also provide the hooks that we will require to achieve the desired presentation using CSS. Finally, we have changed the purely presentational elements b and i to strong and em because the meanings of “strong” and “emphasis” avoid specific connotations of presentation whereas “boldface” and “italic” do not. A good example of the fact that strong is better than b is that if we were to change the presentation of the strong element from boldface to red in the future, we could do it in just one place using CSS and wouldn’t have to touch the HTML at all.

In the previous section, Example 3-2 leverages the power of CSS to overload generic div and span elements. But div and span don’t indicate that we’re delivering a heading followed by a list, which HTML allows us do. Example 3-3, therefore, presents the best example of how we can use HTML to reflect the information architecture of the New Car Reviews module.

<div id="nwcrev">
   <h3>
      New Car Reviews
   </h3>
   <cite>
      <a href="http://...">The Car Connection</a>
   </cite>
   <ul>
      <li class="beg">
         <p>
            <strong>2009 Honda Accord</strong>
            <em>(from $21,905)</em>.
         </p>
         <a href="http://.../reviews/00001/">Read the review</a>
      </li>
      <li class="mid">
         <p>
            <strong>2009 Toyota Prius</strong>
            <em>(from $22,000)</em>.
         </p>
         <a href="http://.../reviews/00002/">Read the review</a>
      </li>
      <li class="end">
         <p>
            <strong>2009 Nissan Altima</strong>
            <em>(from $19,900)</em>.
         </p>
         <a href="http://.../reviews/00003/">Read the review</a>
      </li>
   </ul>
   <form method="post" action="http://.../email/">
      <p>
         Get our most recent reviews each month:
      </p>
      <label for="nwcreveml">Email</label>
      <input type="text" id="nwcreveml" name="nwcreveml" value="" />
      <p class="action">
         <input type="submit" id="nwcrevsub" name="nwcrevsub" value=
            "Sign Up" />
      </p>
   </form>
</div>

First, we have replaced the span elements at the top of the module with an h3 element for the header and a cite element for the name of the provider of the reviews. These elements carry more meaning about your information than simply calling the elements “spans.” In addition, we have used a ul element and multiple li elements to construct the list of reviews, since these also are a better reflection of what the elements really contain. Finally, we have used a label element for the label associated with the email address input. The label element in HTML is often overlooked, but is an important element that conveys valuable information and enables useful features in many browsers; its for attribute specifies the ID of the element to which the label pertains, in this case the input element for the email address.

We have also added IDs and classes to several of the elements to add more meaning about their roles and to provide the hooks that we may require to achieve a desired presentation using CSS. For example, we have added beg, mid, and end to the list items based on their places in the list. The hooks are also useful in JavaScript.

One way to test how well we have reflected the information architecture for a module is to observe how a browser renders it, with none of our styles applied. Figure 3-2 shows how the New Car Reviews module of Example 3-3 is rendered by most browsers by default. As you can see, the default appearance reveals the information architecture of the module rather well.

Figure 3-2. The default rendering of Example 3-3

The original developer of Example 3-1 may have rejected the use of a ul list because she didn’t think the bullet-list layout style was appropriate. But all browsers have supported powerful enough CSS for several years to let you make a list look almost any way you want.

Example 3-4 presents the CSS that makes the New Car Reviews module look like Figure 3-1. It assumes you have first applied the browser reset and font normalization CSS presented at the end of Chapter 4.

#nwcrev
{
   position: relative;
   width: 280px;
   padding: 9px;
   border: 1px #333 solid;
}
#nwcrev h3
{
   position: absolute;
   font: normal 123.1% arial;
}
#nwcrev cite
{
   display: block;
   width: 280px;
   margin-top: 3px;
   font: normal 85% verdana;
   text-align: right;
}
#nwcrev cite a
{
   color:#999;
}
#nwcrev ul
{
   margin: 10px 0;
}
#nwcrev li.beg
{
   margin-bottom: 8px;
}
#nwcrev li.mid
{
   margin-bottom: 8px;
}
#nwcrev li p
{
   text-align: left;
}
#nwcrev li em
{
   color: #999;
   font-style: italic;
}
#nwcrev li a
{
   color: #999;
   font: normal 85% verdana;
}
#nwcrev label
{
   display: block;
   margin: 5px 0 2px;
   font: normal 85% verdana;
}
#nwcrev #nwcreveml
{
   width: 274px;
}
#nwcrev .action
{
   margin-top: 10px;
   text-align: right;
}

A module whose HTML reflects its information architecture is more reusable, maintainable, and reliable because it is more descriptive and honest. The following list, adapted from research at Yahoo! by Nate Koechley et al., describes why well-constructed HTML offers these benefits, and lists a number of others. Well-constructed HTML has the following characteristics:

Table 3-1 presents a list of HTML tags to avoid; these tags are generally either presentational in nature or deprecated. We could present a number of tag attributes as well (e.g., bgcolor, border, etc.), but that list would be very long indeed, given the formatting options that have made their way into HTML over the years. Suffice it to say that if you find yourself considering any attribute with more presentational implications than uses for information architecture, you can be sure there is a better option in CSS. To learn more about any of the tags in Table 3-1, look at the index of detailed descriptions provided by the W3C at http://www.w3.org/TR/html401/index/elements.html.

Table 3-2 presents a list of HTML tags that offer sound, semantic descriptions about what they enclose along with brief explanations of where to apply them. Examples of useful tags that tend to be forgotten include label, cite, dl, dt, and dd. By making good use of meanings that HTML provides for tags intrinsically, you can take advantage of the markup itself to provide meaning where you may have otherwise needed to use a class name. A rich use of tags also frequently can give you the uniquely identifiable hooks on which to hang your CSS. To learn more about the tags in Table 3-2, look at the index of descriptions provided by the W3C at http://www.w3.org/TR/html401/index/elements.html.

You can assign any element in HTML an ID using the id attribute and a class using the class attribute. Because you should use an ID only once per page, they provide a great way to create a unique scope of sorts for working with a module. For instance, refer to the outermost div element with the ID of nwcrev for the New Car Reviews module in Example 3-3. By giving this module an ID, you can focus specific CSS on that module, as shown in Example 3-4, and easily access the module’s elements in the DOM via JavaScript (see Chapter 5). Classes let you do the same for collections of semantically similar elements all at once. This is because classes are intended to be used on a page any number of times.

Don’t confuse the id attribute with the name attribute. In various form inputs, the name attribute lets you give names to input values; these names are passed along with the values for scripts on the server side.

There are a lot of opinions about naming conventions for IDs, classes, and names, but everyone can agree that establishing some sort of convention is important. In large-scale HTML, a good naming convention is key to modularity. One convention, demonstrated earlier in Example 3-3, is to use short groups of three to six characters for naming (e.g., nwcrev is the ID for the New Car Reviews module). From here, you can append other name segments of three or four characters to create further qualified names for use deeper within the module (e.g., nwcreveml for the id and name attributes of the email address text field).

Using fully qualified names like this promotes modularity because you can be assured that anywhere you use this module, its names will not conflict with those used by other modules. For example, if you were to place the New Car Reviews module on a page with another module that also contained a similar form input field for an email address, this naming convention would ensure that the inputs of the two modules would be passed to the server-side script with different names.

Because using short, augmentable name segments is compact and works well, it’s the convention that we employ throughout this book. That said, the exact convention is not what is important here; whatever conventions you prefer, establishing a system of unique qualification that ensures modularity is the key.

XHTML 1.0, the latest version of XHTML from the W3C to advance past the working draft stage, is a reformulation of HTML 4.01 in XML 1.0. This reformulation provides additional rigor and formality that earlier versions of HTML were never intended to have. Because XHTML conforms to XML, it offers web developers several benefits. First and foremost, XHTML’s strictness results in cleaner, more consistent code that promotes better maintainability and reliability. Next, XHTML is readily viewed, edited, and validated with standard XML tools. In addition, XHTML can utilize applications that rely upon either the HTML DOM or the XML DOM. Finally, XHTML is more likely to interoperate within various XHTML environments in the future should XHTML continue to advance. Since XHTML can be written to operate in older browsers as well as in XHTML-conforming browsers, there are few reasons not to start writing HTML using this higher standard.

Fortunately, it is relatively easy to make the HTML that we write conform to the higher standards of XHTML. The examples of HTML in this chapter, as well as in the rest of the book, are actually XHTML, for the most part. Most HTML is compatible with XHTML, but there are a few guidelines that you need follow to ensure your code conforms to XHTML while continuing to render properly in older and XHTML-conforming browsers alike. A list of these guidelines is presented below.

<!-- Yes, XHTML -->
<strong>2009 Nissan Altima</strong>
<em>(from $19,900)</em>.

<!-- Not XHTML! -->
<strong>2009 Nissan Altima<em>
(from $19,900)</strong></em>.

<!-- Yes, XHTML -->
<li class="mid">
   <p>
      <strong>2009 Toyota Prius</strong>
      <em>(from $22,000)</em>.
   </p>
   <a href="http://.../reviews/00002/">Read the review</a>
</li>
<li class="end">
   <p>
      <strong>2009 Nissan Altima</strong>
      <em>(from $19,900)</em>.
   </p>
   <a href="http://.../reviews/00003/">Read the review</a>
</li>

<!-- Not XHTML!-->
<li class="mid">
   <p>
      <strong>2009 Toyota Prius</strong>
      <em>(from $22,000)</em>.
   </p>
   <a href="http://.../reviews/00002/">Read the review</a>
<li class="end">
   <p>
      <strong>2009 Nissan Altima</strong>
      <em>(from $19,900)</em>.
   </p>
   <a href="http://.../reviews/00003/">Read the review</a>

<!-- Yes, XHTML -->
<input type="submit" id="nwcrevsub" name="nwcrevsub" value="Sign Up" />

<!-- Not XHTML! -->
<input type="submit" id="nwcrevsub" name="nwcrevsub" value="Sign Up">

<!-- Yes, XHTML -->
<label for="nwcreveml">Email</label>

<!-- Not XHTML! -->
<LABEL FOR="nwcreveml">Email</LABEL>

<!-- Yes, XHTML -->
<input type="text" id="nwcreveml" name="nwcreveml" value="" />

<!-- Not XHTML! -->
<input type=text id=nwcreveml name=nwcreveml value='' />

RDFa is fundamentally about creating triples that consist of a subject, predicate, and object to form statements. The subject is what you are making a statement about. The predicate is the relationship that the statement defines. The object is the resource with which the subject forms a relationship. You form these triples by adding attributes to your HTML. Some attributes are already defined as part of XHTML (see Table 3-3), while others are specific to RDFa (Table 3-4).

Because XHTML is extensible while HTML is not, RDFa has only been specified in the working draft for XHTML 1.1. Web developers can use RDFa markup inside HTML 4.01 without experiencing adverse effects in various browsers, since the designers of RDFa expected this use case. However, RDFa will not validate in HTML 4.01. RDFa attributes validate using the XHTML1.1+RDFa DTD.

RDFa statements built from a subject, predicate, and object are based on a vocabulary to help convey certain meanings. You can define a vocabulary yourself or use existing vocabularies that RDFa processors are likely to understand. One such vocabulary is the Dublin Core vocabulary. This vocabulary defines properties about common resources found in documents, such as title, creator, and subject.

Example 3-5 uses RDFa to enhance the information architecture that we presented in Example 3-3 for the New Car Reviews module. In Example 3-5, we have added RDFa attributes to annotate the three new car reviews. This produces three triples (see Table 3-5). For each statement, the subject (a URI) is defined by the about attribute added to each list item. The property attribute for each strong element specifies dc:title for each statement’s predicate. The object for each statement is the literal enclosed within each strong element itself. The value dc:title for the predicate comes from the Dublin Core vocabulary. To use this vocabulary, we have to define a namespace and refer to it using the xmlns:dc attribute, typically within a higher-level element of the page, such as the body element (see Example 3-6).

<div id="nwcrev">
   <h3>
      New Car Reviews
   </h3>
   <cite>
      <a href="http://...">The Car Connection</a>
   </cite>
   <ul>
      <li class="beg" about="http://.../reviews/00001/">
         <p>
            <strong property="dc:title">2009 Honda Accord</strong>
            <em>(from $21,905)</em>.
         </p>
         <a href="http://.../reviews/00001/">Read the review</a>
      </li>
      <li class="mid" about="http://.../reviews/00002/">
         <p>
            <strong property="dc:title">2009 Toyota Prius</strong>
            <em>($22,000)</em>.
         </p>
         <a href="http://.../reviews/00002/">Read the review</a>
      </li>
      <li class="end" about="http://.../reviews/00003/">
         <p>
            <strong property="dc:title">2009 Nissan Altima</strong>
            <em>($22.95)</em>.
         </p>
         <a href="http://.../reviews/00003/">Read the review</a>
      </li>
   </ul>
   <form method="post" action="http://.../email/">
      <p>
         Get our most recent reviews each month:
      </p>
      <label for="nwcreveml">Email</label>
      <input type="text" id="nwcreveml" name="nwcreveml" value="" />
      <p class="action">
         <input type="submit" id="nwcrevsub" name="nwcrevsub" value=
            "Sign Up" />
      </p>
   </form>
</div>

<body xmlns:dc="http://purl.org/dc/elements/1.1/">
.
.
.
</body>

Example 3-7 presents a further enhancement to the information architecture presented in Example 3-3 for the New Car Reviews module. In Example 3-7, we have annotated the title and creator for the reviews as a whole. In addition, we have used the content attribute to change the object of the triple for each review. By doing so, we can provide something more descriptive than what appears in the markup. Altering the content like this can be useful when you need to use different representations of information in the human Web and the data Web (the human Web did not require this clarification in the title, for example). The enhancements in Example 3-7 produce five triples (see Table 3-6).

<div id="nwcrev" about="http://.../reviews/">
   <h3 property="dc:title">
      New Car Reviews
   </h3>
   <cite property="dc:creator">
      <a href="http://...">The Car Connection</a>
   </cite>
   <ul>
      <li class="beg" about="http://.../reviews/00001/">
         <p>
            <strong property="dc:title" content="Review for 2009 Honda
               Accord">2009 Honda Accord</strong>
            <em>(from $21,905)</em>.
         </p>
         <a href="http://.../reviews/00001/">Read the review</a>
      </li>
      <li class="mid" about="http://.../reviews/00002/">
         <p>
            <strong property="dc:title" content="Review for 2009 Toyota
               Prius">2009 Toyota Prius</strong>
            <em>(from $22,000)</em>.
         </p>
         <a href="http://.../reviews/00002/">Read the review</a>
      </li>
      <li class="end" about="http://.../reviews/00003/">
         <p>
            <strong property="dc:title" content="Review for 2009 Nissan
               Altima">2009 Nissan Altima</strong>
            <em>(from $19,900)</em>.
         </p>
         <a href="http://.../reviews/00003/">Read the review</a>
      </li>
   </ul>
   <form method="post" action="http://.../email/">
      <p>
         Get our most recent reviews each month:
      </p>
      <label for="nwcreveml">Email</label>
      <input type="text" id="nwcreveml" name="nwcreveml" value="" />
      <p class="action">
         <input type="submit" id="nwcrevsub" name="nwcrevsub" value=
            "Sign Up" />
      </p>
   </form>
</div>

In the end, both Example 3-5 and Example 3-7 provide additional meaning for our module because they go beyond the HTML markup to add annotations that tell a processor exactly what certain pieces of the markup are. So, instead of having to make an assumption about what the cite element represents in Example 3-7 (e.g., The Car Connection has been cited as having something to do with the division that encloses it), you now know specifically that The Car Connection is the creator of the content at http://.../reviews/, which is a resource with the title New Car Reviews.

The value of RDFa depends on the presence of processors that do something useful with the RDFa statements in web applications. With a groundswell of interest in using RDFa data at major websites such as Yahoo! and Google, it’s possible that modern web applications will soon be expected to provide relevant annotations as a matter of course.