On the topic of meaningful and lightweight markup, I've chosen to go with HTML 4.01 Strict as the DOCTYPE, favoring it above XHTML 1.0 Strict and HTML 5. I'll briefly explain my reasoning.

XHTML 1.0 Strict: This is what many of us in the industry, including myself, have been using for the past few years. However, Dave Shea offers a compelling argument to drop XHTML with an eye towards HTML 5:

HTML 5: In a nutshell, HTML 5 is the next major version of the hypertext markup language. The good news is meaningless div and span elements will be replaced by more meaningful elements such as nav, header, and video.

This means instead of marking up something such as

<div class="header">
  <h1>Page Title</h1>
</div>

or

<object><param/><embed src="http://vimeo.com/3956190"></embed></object>

we'll be able to mark up the same HTML like this:

<header>
  <h1>Page Title</h1>
</header>

and this:

<video src="http://vimeo.com/3956190">

The bad news is as of the publication of this case study, HTML 5 is not supported adequately by major browsers (notably Internet Explorer). Estimates range from months to years before HTML 5 is fully supported and therefore a viable option for all of us creating websites.

An alternate approach is to maintain that same watchful eye towards HTML 5 by writing markup using current DOCTYPEs but with semantic, HTML 5-like class names. Jon Tan covers this approach beautifully in "Preparing for HTML 5 with Semantic Class Names" (http://jontangerine.com/log/2008/03/preparing-for-html5-with-semantic-class-names).

For example, using the nav element, HTML 5 markup would be

<nav>
  <ul>
    <li><a href="">Menu item 1</a></li>
    ...
  </ul>
</nav>

while our semantic, HTML 5–like markup using HTML 4 or XHTML 1 would be

<div class="nav">
  <ul>
    <li><a href="">Menu item 1</a></li>
    ...
  </ul>
</div>

However, the drawback to this approach is you potentially end up with a lot of extra divs. If our goal is meaningful and lightweight markup, the most optimal markup right now would instead be the following:

<ul class="nav">
  <li><a href="">Menu item 1</a></li>
  ...
</ul>

So, my opinion about HTML 5? We'll all adapt just fine when it's ready for prime-time and fully supported. The mental shift will be minimal. Until then, I'll keep coding the way we've always done it.

For additional resources on the topic of HTML 5, visit the following:

When I first began coding CSS-styled sites several years ago, it was common to declare a few "global" styles at the top of the master style sheet: body, a img, h1, h2, h3, and so on. What was done back then as a means of overriding the default styles of any given browser eventually evolved into today's practice of using a "reset" style sheet, typically named reset.css.

As stated by the team at Yahoo, a reset style sheet "removes and neutralizes the inconsistent default styling of HTML elements, creating a level playing field across A-grade browsers. . ." (http://developer.yahoo.com/yui/reset/). I personally prefer Eric Meyer's Reset CSS, which is used in this case study. You can download this style sheet here: http://meyerweb.com/eric/tools/css/reset/.

I use a single style sheet, master.css, to import any number of style sheets for a site. I declare the reset style sheet first, thereby allowing any style sheets that come after to override the reset styles as needed:

@import url("reset.css");
@import url("screen.css");
@import ...

All styles for screen display are listed in screen.css. In the case study site, three additional style sheets are used:

We could have easily inserted the styles from autocomplete.css and datepicker.css into screen.css, but for the purposes of walking you through this case study, they remain separate.

Grids have been in use in graphic design for several decades, but only in the last few years have they really found favor in the minds and voices of web designers—and with good reason at last. Wikipedia offers a succinct description of the grid and its merits, "A typographic grid is a two-dimensional structure made up of a series of intersecting vertical and horizontal axes used to structure content. The grid serves as an armature on which a designer can organize text and images in a rational, easy to absorb manner" (http://en.wikipedia.org/wiki/Grid_(page_layout)).

Grids are comprised of things such as columns, rows, margins, gutters (the space between columns and rows), flow lines (horizontal divisions), and other components. In a medium such as print design, the width and height for each of these components are bound to the finished size of the material; their dimensions are easily calculated by the designer. In web design, however, width dimensions are often much more calculable than height dimensions. This is because of the potentially endless height of a scrollable page.

Accordingly, the armature for the Roma Italia focuses on vertical divisions. Figure 10-2 shows the grid for the site.

Figure 10.2. The 12-division grid used to design the site

You can toggle this grid on and off by uncommenting the following markup:

<div id="grid"><img src="img/grid.png" alt="" width="1090" height="1380"></div>

This is even easier to do if you have a browser plug-in such as Firebug for Firefox (http://getfirebug.com/) that allows you to temporarily alter a document's markup within the browser. With Firebug open, double-click the body tag to reveal the comment and then edit the HTML right there in Firebug.

Figure 10.3. Each column is 80 pixels wide with a 10-inch gutter to the right

As you can see, the grid is divided into 12 columns. Each column is 80 pixels wide with a 10-pixel gutter to the right of each column (as shown in Figure 10-3), which produces a layout 1080-pixel wide. An offset of 10 pixels—essentially an extra gutter—is added to the left margin to balance the grid. However, this offset as well as the gutter alongside the last column to the right are invisible to the viewer. You could argue the grid is actually 1070 pixels wide with these invisible components removed, or conversely, 1090 pixels with the same components made visible. Regardless, our grid is based on an overall measure of 1080.

For the most part, text and images align with columns and gutters. Of course, that's the point of using a grid. Yet you'll notice I haven't aligned every element perfectly. What's important to note here is that a grid doesn't necessarily dictate the exact placement of items. Rather, it facilitates the general positioning of elements, leaving precise positioning to the good judgment of the designer. In Making and Breaking the Grid (Rockport Publishers, 2005), Timothy Samara describes this concept perhaps better than I:

But the real power of a grid is found not just in a single page but in the composition as a whole. For example, in a printed brochure, a grid serves to unify the placement of elements throughout the brochure. Similarly, if Roma Italia were a real site, all of its pages—not just the two you see here—would leverage the same grid, yielding visual continuity for the user and limitless layout options for the designer.

I've offered only a cursory discussion of grids in this section. You can find many more resources at The Grid System (http://www.thegridsystem.org/) and in Smashing magazine's "Designing with Grid-Based Approach" (http://www.smashingmagazine.com/2007/04/14/designing-with-grid-based-approach/).

Type this heading into your browser's address bar and you'll discover the answer. This simple site, developed by Dan Cederholm, circled the web in 2008 as virtual propaganda discrediting the myth that websites must look exactly the same in any and all browsers. It was a wake-up call to the web development community to become a little more progressive in its approach to markup, rather than being enslaved by absolute uniformity. In a single word, Dan's site denounced the labeling of visual inconsistency as the red-headed stepchild.

In Roma Italia, the most obvious visual inconsistency deals with the multiple background feature. This feature will allow for several background images per a single element, whereas currently only one image per element is allowed. Rounded corner aficionados rejoice.

As of this writing, Safari is the only major browser to support multiple backgrounds. (Interestingly enough, Safari has supported the feature since version 1.3, dating all the way back to 2005!) This means that in browsers such as Firefox and Internet Explorer, the site will look slightly different. Not only is this intentional for the purpose of this case study, but it's also to demonstrate that it's perfectly legitimate to deliver a slightly different experience to different browsers with no negative effect on the overall user experience.

Multiple backgrounds, which are sure to be a boon to web professionals once fully supported, are easy to style. Simply separate each image and its values with a comma:

background: url(image1.png) no-repeat top left,
  url(image2.png) no-repeat top right,
  url(image3.png) no-repeat bottom left;

Alternatively, properties and values can be defined separately:

background-color: #000;
background-image: url(image1.png), url(image2.png), url(image3.png);
background-repeat: no-repeat;
background-position: top left, top right, bottom left;

Multiple backgrounds are used in our case study site in a couple places, as shown in Figure 10-4. Notice the differences between Safari and Firefox and Internet Explorer.

Figure 10.4. Differences in the background images between Safari (left) and Firefox and Internet Explorer (right)

Two background images are used in the body to give the site its background texture: the large dark brown image and light brown stripe with a subtle gradient, respectively named bg-dark.jpg and bg-light.jpg. The CSS looks like this:

body {
  background: url(../img/bg-dark.jpg) repeat-x top center,
  url(../img/bg-light.jpg) repeat-x 239px left;
  background-color: #f1efe8;
  }

Because Firefox and Internet Explorer don't yet support multiple backgrounds, and if we leave the CSS as shown, neither image will show up. This will leave the background completely empty, which isn't desirable. So, as a means of at least displaying the dark image, we insert the following duplicate property above the first:

background: #f1efe8 url(../img/bg-dark.jpg) repeat-x;

Firefox reads this property and ignores the other. We repeat the same property in ie.css as Internet Explorer isn't fond of this little hack we've thrown together. The final CSS found in screen.css is as follows:

body {
  background: #f1efe8 url(../img/bg-dark.jpg) repeat-x;
  background: url(../img/bg-dark.jpg) repeat-x top center,
    url(../img/bg-light.jpg) repeat-x 239px left;
  background-color: #f1efe8;
  }

Let's be clear: This isn't the most efficient way to accomplish what we've shown here. First, we could have used a single image that combined the dark and light designs, eliminating the need for multiple background images. Second, we're adding duplicate markup to force Firefox and Internet Explorer to display at least one image. However, the point of these inefficiencies is solely to defend insignificant visual inconsistencies from browser to browser and to demonstrate what's around the corner with multiple backgrounds. For the sake of the collective industry, let's keep our hopes up that the corner is closer than expected.

The attribute selector eliminates the need to add a class or ID to an element by referencing any attribute or attribute value contained in the element. It can be used on virtually any element with inherent attributes. For example, img[alt] targets an attribute while img[src="small.gif"] targets an attribute value. Further, similar attribute values can be targeted using syntax strings such as img[src^="sm"] which will target any value beginning with the prefix "sm" (e.g., "small"). See "CSS3: Attribute selectors" (http://www.css3.info/preview/attribute-selectors/) for additional examples.

Attribute selectors come in handy in a variety of situations, but probably the most useful is with forms. If elements are styled with a generic hook of input { }, all input elements within the form will be styled. This means that if you're hoping to target text fields only or the submit button only, you're relegated to adding superfluous classes and IDs to do so. The attribute selector, therefore, is a clean way to target specific elements.

Figure 10.5. This search field uses two input elements, each targeted by an attribute selector

The search field near the top of the site serves as our attribute selector example (see Figure 10-5). The HTML is as follows:

<form action="#" method="get" accept-charset="utf-8">
  <fieldset>
    <legend></legend>
    <label for="search-input">Search</label>
    <input type="text" id="search input" name="search" value="" title="Search">
    <input type="image" name="" src="img/search-go.gif">
  </fieldset>
</form>

Here, we'd like to style the text field with several properties and float search-go.gif to the left. In bold are the two input elements we'll target with an attribute selector. Notice the absence of a class or ID selector within each input element. This is because we can target each using the type attribute, and we do so like this:

#header form input[type="text"] {
  display: block;
  ...
  background: url(../img/search-bg.gif) no-repeat;
  }


#header form input[type="image"] {
  float: left;
  }

Any input element containing the attribute type="image" will be floated left, while any input element containing the attribute type="text" will be styled as we've indicated. Additionally, this same syntax is used in jquery.plugins.js to add jQuery and AJAX functionality:

$('#header form input[type="text"]').searchField();

Both jQuery and AJAX will be treated in a later section.

In the center of the Roma Italia site, toward the bottom of the page, you'll see a Voices Around the World featurette. If this featurette were real, Twitter updates (tweets) from any users who include the hash tag #romaitalia in their tweet would appear randomly on the map based on the Twitter user's geographical location. Visitors to the site could click these randomized quotes and be taken to page with the full tweet, the author's user name, and tweets from other Roma Italia fans as a means of learning about Rome real-time via Twitter updates. The tweets displayed in the case study are fictitious, but you may follow @roma_italia, a real Twitter account I've set up for this case study.

Figure 10.6. Map markers that fade in and out with additional text revealed on hover

The markers that fade in and out every couple of seconds are rather complex codewise (see Figure 10-6), and we'll use the markup for these to demonstrate the CSS 3 features box-shadow, RGBa, and text-overflow.

Each marker is composed of three parts: the tweet text, a white background with a drop shadow, and a dot image for the map marker. The marker is wrapped in a list item (li), which is housed in an unordered list (ul) containing the world map background image:

<ul>
  <li class="l1" id="map2" style="top: 61px; left: 53px;"><a href="#">
  <em>"Absolutely divine. Don't skip the Il Vittoriano. Its size alone is
  impressive. There's a stunning view from the top."</em></a></li>
  <li>...</li>
</ul>

We style the ul with the following properties:

#voices ul {
  position: relative;
  width: 310px;
  height: 178px;
  background: url(../img/bg-map.gif) no-repeat;
  }

Notice we've set the position to relative. This allows us to absolutely position each list item relative to the ul. Otherwise, the list item would position relative to another parent element, most likely the body. (See Chapter 3 for a refresher on absolute positioning.)

Each map marker li is styled accordingly:

#voices ul li.l1 {
  position: absolute;
  adding-top: 16px;
  background: url(../img/mapmarker-dot.png) no-repeat 2px top;
  }

The map marker dot is embedded as a background image, and the class l1 indicates location number one (dot to the right), while l2 indicates location number two (dot to the left). Absent are the location properties that position each marker on the map. This is because we dynamically position each marker as it fades in using an inline style, which for this particular marker is style="top: 61px; left: 53px;". That is, 61px from the top of the ul and 53px from the left of it.

The white background on which the tweet text rests is slightly transparent and has a drop-shadow on the left, right, and bottom edges. These two styles are accomplished using RGBa and box-shadow, respectively:

#voices ul li.l1 a {
  display: block;
  padding-left: 11px;
  font: 11px/14px Georgia, serif;
  color: #32312a;
  -webkit-box-shadow: 0 2px 3px rgba(0, 0, 0, 0.35);
  -moz-box-shadow: 0 2px 3px rgba(0, 0, 0, 0.35);
  background-color: rgba(255, 255, 255, 0.78);
  }

As box-shadow and RGBa are covered in Simon's case study in Chapter 11, please refer to his text for an explanation of these two features. Note, however, that RGBa opacity differs from another CSS 3 feature called opacity. RGBa opacity can be applied to a specific property, such as background, and it will only affect that property. opacity, on the other, affects everything in the element it modifies, such as this:

#voices ul li.l1 a {
  opacity: 0.35
  ...
  }

The values for opacity are similar to RGBa: 0 (fully transparent) to 1 (full opaque). However, I stress that this affects the entire element. Had we used it here, not only the white background would be 35 percent opaque but the tweet text, too.

When the user mouses over a map marker, the display of the marker changes, as shown in Figure 10-7.

Figure 10.7. Full text is displayed on hover

This is where text-overflow comes into play. I wish I had a dollar for every time I could have used this feature in my career—by now, I'd be penning these words from a beach house in the Bahamas. The good news is that today it's fairly well supported across the major browsers. In fact, IE supports it better than Firefox, as does Safari. text-overflow clips a block of text that is too large to fit within its containing element. Using the value ellipsis appends an ellipsis (. . .) to the clipped text.

For each map marker, text-overflow is used to clip the text to one line:

#voices ul li.l1 a em {
  white-space: nowrap;
  width: 135px;
  overflow: hidden;
  text-overflow: ellipsis;
  -o-text-overflow: ellipsis;
  -moz-text-overflow: ellipsis;
  -webkit-text-overflow: ellipsis;
  }

Because this feature isn't officially supported by each browser—even though all of the major browsers do support it—we've added the prefixes -o- (Opera), -moz- (Mozilla), and -webkit- (Webkit). Then, for the mouseover effect, we add the :hover pseudo-class to the element, change the height to 72px, and set overflow to visible.

#voices ul li.l1 a em:hover {
  white-space: normal;
  overflow: visible;
  text-overflow: inherit;
  -o-text-overflow: inherit;

cursor: hand;
  cursor: pointer;
  background: #fff none;
  height: 72px;
  padding-left: 11px;
  padding-bottom: 5px;
  margin-left: −9px;
  }

And that completes the effect—hat tip to CSS3.info for their text-overflow examples, which were inspiration for the creation of this effect. Other CSS 3 features can also be found at their website: http://www.css3.info/.

For a number of years, px was the de facto standard for sizing text with font-size. It gave designers transferring their design from Photoshop (or other software) to HTML a consistent, absolute unit for text size. Then, as we became more knowledgeable of and concerned with accessibility, relative text size (em or %) gradually became the preferred unit. This enabled low-vision users, and really anybody, to change their browser's default text size permanently via the browser's settings or on-the-fly using the keyboard commands Ctrl+ and Ctrl– (Windows) or Command + and Command –.

Accordingly, and up until recently, all major browsers would scale up or down the size of the text while retaining the formatting and layout of the page. This is commonly called text scaling or text zooming. This adaptation required us to create markup that allowed for relative sizing of any elements containing text. For example, if a div contained text set atop a background image, we would have to either repeat the image as the div grew larger with text scaling or create the image larger than necessary to compensate for growth. This is something I covered in detail in my "The Highly Extensible CSS Interface" series of articles (see http://cameronmoll.com/archives/2008/02/the_highly_extensible_css_interface_the_series/).

However, recent versions of every major browser—Safari, Firefox, Google Chrome, Opera, and yes, Internet Explorer—now default to page zooming instead of text scaling for Ctrl +/– and Command +/– commands. Page zooming literally zooms the entire page—layout, formatting, and text size—in unison. Elements retain their size and shape, which greatly reduces the need to compensate for text scaling. In effect, the browser assumes the burden of relative sizing.

What does all this mean? It means px can again be considered a viable value for font-size. It also means the difference between setting text with absolute units or setting text with relative units may be negligible for users. For you and me, however, the difference is significant. The burden of calculating relative units throughout a CSS document is replaced by the convenience of absolute units—14px is 14px anywhere in the document, independent of parent elements whose font-size may differ.

Bear in mind this case study site is meant to be realistic but experimental, as well. I'm at liberty to explore and ask the questions "what if?" and "why not?". Your projects may not yield the same opportunity, so make the right choice for your audience. As with nearly all of the decisions we make as web professionals, you need to make the right decision based on your audience and users. That is the one constant that will never change with all the changes that have occurred and are bound to occur in our industry. In short, if relative sizing is the right choice for your project, no one else can tell you otherwise—including me.

For additional reading on the debate over px for font-size, check out these articles:

Hanging punctuation is one of those subtle signals that a skilled typographer is behind the design. These feature is available in most of the Adobe family of design applications, but it's not available as a CSS property. Not yet, that is. There's actually a property called hanging-punctuation proposed in the CSS3 spec (see http://www.w3.org/TR/css3-text/#hanging-punctuation), but to my knowledge no current browser supports this property.

Hanging punctuation aligns punctuation marks outside the text block as to not disrupt the visual flow of the text. Figure 10-8 shows an example using quotation marks.

Figure 10.8. An example showing how hanging punctuation (bottom) differs from punctuation aligned with the edge of the text (top). The latter is the default in most graphic design software, as well as text within a browser

This technique is used in three places on the home page: the first line of text beneath the Roma Moleskine heading (see Figure 10-9), the tweet text in the Voices Around the World map markers, and the orange quotation by the Venerable Bede. The last of these is an image, so we'll cover the first one. The same technique is used for the second.

Figure 10.9. Hanging punctuation implemented in Roma Italia

The HTML is straightforward:

<div id="featurette1">
  ...
  <p>
  &ldquo;The ultimate traveler&rsquo;s journal.&rdquo; City maps,
  removable sheets, and a 96-page tabbed archive.</p>
  ...
</div>

The HTML entities “, ’, and ” are curly quotes. These are not necessary for hanging punctuation, but they're yet another subtle signal of good typography. These entities make the source code appear a bit more cluttered to the untrained eye, but the adjusted punctuation rendered by the browser—and noticeable by trained eyes—makes up for the difference.

The CSS is where the magic happens:

#featurette1 p {
  text-indent: -.3em;
  }

And that's it. In your projects, adjust this value depending on the size and family of your typeface.

With a layout as wide as this one, maintaining a measure (or line length) that is suitable for readability becomes an issue. Measure is the width of a block of text, measured by the number of characters (including spaces) per line. There are countless studies and opinions about the optimal number of characters per line, ranging from 45 to 95 characters per line and varying depending on the medium. This section isn't a discussion about optimal measure, rather one about how to maintain a reasonable measure.

Because this layout is a full 1080 pixels wide, it provides an excellent opportunity to try out the multi-column text feature found in the CSS3 spec. This feature is currently supported by WebKit and Mozilla browsers. Other browsers render the text as a single column as wide as the columns combined.

Robert Bringhurst, in his exceptional and typographically replete The Elements of Typographic Style (Hartley and Marks, 2004), suggests 40–50 characters per line for text set in multiple columns. For the sake of convenience, I've followed his recommendation with this layout.

Shown in Figure 10-10 is a snippet from video.html.

Figure 10.10. Multicolumn text layout on the video page

Notice the text is set in two columns. First, the HTML is standard stuff:

<div id="main-video">
  <h3>
  Highlights from a recent vacation to Rome, Italy. Shot with a...</h3>


  <p>I&rsquo;m no video virtuoso. I only dabble with video as time...</p>
  ...
</div>

The CSS, on the other hand, is anything but standard:

#main-video {
  float: left;
  margin: 40px 10px 70px;
  width: 520px;
  -moz-column-count: 2;
  -moz-column-gap: 20px;
  -webkit-column-count: 2;

-webkit-column-gap: 20px;
  }

Here again -moz- (Mozilla) and -webkit- (Webkit) are prefixed out of necessity. Notice there are two properties at play: column-count and column-gap. These properties are fairly easy to understand and to use—set a value for the number of columns you want, and select a value for the gap between them. The entire block of text is then automatically set in the number of columns specified. A third property, column-rule, allows you to add a border between the columns (e.g., column-rule: 1px solid #000;).

Questions about the practicality of multiple-column text on the web and issues with scrolling up and down the page are warranted, but I'm confident that in the hands of a skilled typographer, multicolumn layout has the potential to extend the typography options available to us on the web.

The words of Jeffrey Veen, founder of Typekit (http://typekit.com/), are the perfect introduction to this section:

Excellent questions, Jeffrey. It's highly likely that by the time this book has hit store shelves and worked its way into your hands, Jeffrey's Typekit product will probably have resolved, in a big way, the very questions he's asking. Typekit attempts to resolve the implementation and security issues (discussed later in this section) with @font-face by hosting typefaces centrally that have already been approved by type foundries for font linking (see Figure 10-11).

Figure 10.11. Typekit offers web font linking without the hassle of @font-face implementation and security issues

Simply put, @font-face provides us with the ability to use virtually any font in our designs rendered as HTML text without worrying about whether or not that font is installed on the user's machine. This is commonly referred to as font linking or font embedding. Instead of this at the top of our document

body {
  font-family: Georgia, serif;
  ...
  }

we can do this

@font-face {
  font-family: "Garamond Premier Pro";
  src: url(fonts/GaramondPremrPro.otf);
  }

Then, we reference the font-family as we're already accustomed to doing:

h1 {
  font-family: "Garamond Premier Pro", serif;
  }

I get giddy just typing all this (geekness, I know). But imagine using any typeface you owned in your site's design and having your text rendered as real, HTML text—no sIFR, no Cufón, no images. You're probably just as giddy now, too.

Of course, if things were that easy, we would have been began using @font-face seven years ago. Indeed, there are caveats. First is—you guessed it—browser support. Safari 3 and newer and Firefox 3.1 and newer support @font-face. So does Internet Explorer 4 and newer. However, IE staunchly supports only the .eot (Embedded OpenType) format, which is essentially a Microsoft proprietary font format. .eot files can be created only from .ttf (TrueType) files, and other font formats such as .otf (OpenType) must be converted to .ttf to then be converted to .eot. No wonder @font-face hasn't taken off.

Second, type foundries and type vendors have been very apprehensive about font linking on the web, and their concern is twofold: because font files are stored on the site and therefore publicly accessible, they may be vulnerable to downloading and illegal use, and because many of their end user license agreements (EULAs) have not been updated to allow for font linking.

However, the good news is also twofold: new technologies are emerging, such as Typekit, that eliminate the two concerns just mentioned, and @font-face encourages the use of typefaces other than the standard set we're all used to (Arial, Georgia, etc.), which inevitably will increase the demand for commercial typefaces. Therefore, type vendors and foundries have a vested interest in seeing font linking and embedding flourish. In fact, during the course of writing this chapter, several foundries have announced new typefaces available for font linking on the Web, and even some have announced significant changes to their EULAs.

Museo Sans, see Figure 10-12, is a typeface by designer Jos Buivenga, released in 2008. In particular, Museo Sans 500 is free, and it's the weight I've used here. Best of all the EULA allows for font linking. (Note that Gotham, the typeface used in the logo and in the titles overlaying the fading feature images, would have been my first choice for font linking. Alas, their EULA didn't allow for it when this site was coded.)

Figure 10.12. Museo typeface samples. Image courtesy of MyFonts.com

In Roma Italia, @font-face is used to demonstrate what is possible now and in the near future. In screen.css, you'll see the following code near the top of the document:

@font-face {
  font-family: "Museo Sans X";
  src: url(../fonts/MuseoSans_500.otf);
  }

Museo Sans is used in several headings and in the top navigation (see Figure 10-13):

#home h3, #home h4, #home #header h2, #home #header ul a {
  font-family: "Museo Sans X", "Lucida Grande", "Lucida Sans Unicode",
    Arial, sans-serif;
  }

Figure 10.13. Museo Sans is the typeface used in the top navigation

Notice that I've still indicated backup font choices in the event that the user's browser doesn't support @font-face. Also notice that the name of the typeface is Museo Sans X. When you establish @font-face in your CSS, you can name the font-family whatever you want. I could have used Musei Vaticani for all it matters as long as I reference the proper font file (MuseoSans_500.otf). Because Museo Sans is free, you may already have it installed on your machine. I specifically added the X to be sure you're seeing @font-face at work with my copy of Museo Sans and not a local copy on your machine.

Note that I've not converted the Museo Sans .otf file to .eot and therefore Internet Explorer will not recognize it. If you're seeing Museo Sans in Internet Explorer, you're seeing Cufón at work, not @font-face (see the next section).

For additional reading, see the following:

I've posted an extensive tutorial about Cufón on my personal website, which you can find at this address: http://cameronmoll.com/archives/2009/03/cufon_font_embedding/. Because of this, I'll offer only a cursory examination of Cufón in this case study. In short, Cufón allows you to render HTML text in the typeface of your choice without requiring any images or the use of @font-face (see Figure 10-14).

First things first. sIFR, as many of you may be aware, is a means of replacing "short passages of plain browser text with text rendered in your typeface of choice, regardless of whether or not your users have that font installed on their systems" using a combination of Flash and JavaScript (see http://www.mikeindustries.com/blog/sifr/). Shaun Inman, Mark Wubben, Mike Davidson, and several others put in many long hours developing and refining IFR and sIFR, and we all owe them our gratitude for moving forward in a big way the state of typography on the web. What @font-face lacked in browser support and type foundry endorsement over the years, sIFR made up for in the same period.

For many of us, however, the Flash part of these technologies often makes it difficult to set up and use. Cufón, on the other hand, can be set up and run on your site in about 5 minutes. Because of this, I personally see Cufón as an good interim step between sIFR and @font-face should you not have the option of font linking available to you.

Figure 10.14. Cufón's typeface script generator

Here's how Cufón works:

And that's it. Cufón is currently supported by IE 6, 7, and 8, Firefox 1.5 and above, Safari 3 and above, Opera 9.5 and above, and Google Chrome. In the case study site, I've included Cufón in addition to @font-face, so you can explore the two options. Be aware Cufón shares the same caveat as @font-face when it comes to licensing—the EULA for the typeface you choose must allow for font embedding on the web.

Note that I've wrapped Cufon.replace in a conditional comment because IE won't read the .otf font file we're using for @font-face. Therefore, Cufón becomes a replacement for @font-face in IE for the purposes of this case study. If you'd like to see Cufón work in any browser other than IE, simply remove the conditional comment, and it will override @font-face.

AJAX, shorthand for Asynchronous JavaScript and XML, typically includes at least three components:

Asynchronicity is the key component of AJAX—or any rich Internet technology, for that matter—as it provides that native-application feel within the web environment. Instead of the traditional request and response model that fetches an entire page with a full trip to the server, asynchronicity means data is fetched only for a select portion of the page (e.g., user name availability when registering an account).

In Roma Italia, we fake asynchronous server communication for the purposes of demonstration by using a little JavaScript and by fetching data from a few static PHP pages:

Faking asynchronicity merely allows you to download the code samples and open the interface on any machine running PHP, without requiring true server communication.

We'll take a look at the code for auto-complete feature right after the jQuery segment.

Karl Swedberg and Jonathan Chaffer's very useful Learning jQuery (Packt Publishing, 2007) describes jQuery as a "general-purpose abstraction layer for common web scripting." I like to think of it as "JavaScript for scripting noobs like me."

jQuery enables you to do the following:

And it allows you to do all this without writing lines and lines of JavaScript. Even better, it leverages CSS syntax for using the selectors in your document as the hooks for creating interaction.

Let's pick apart a sample from another site I've coded to understand the components of jQuery. This is another fictitious site creating for instructional purposes and it can be found at http://cameronmoll.com/articles/widget/.

Figure 10.15. The Widget demonstration site created for my "The Highly Extensible CSS Interface" series

We'll use the Dismiss button located in the yellow notification bar at the top of the page (see Figure 10-15). When clicked, the yellow bar slowly slides upward until it is no longer visible.

Here's the code we add to the button's anchor tag:

$('#alert').slideUp('slow'),

Following is a description of each component:

This code can be added either inline or in a separate .js file (or dynamically), the latter being the more optimal method. But here's the real kicker: I didn't have to come up with any of this code on my own. The construct, method, and string came prebuilt with jQuery. I just had to know I wanted the element to slide up slowly, and then I looked up the appropriate references in the jQuery library that corresponded with the animation and movement I was seeking. Boom. Done.

Now that we've taken care of the instructional housekeeping, let's take a look at an example of AJAX and jQuery working together in Roma Italia. The feature we'll explore is the search feature. Earlier in this case study, we looked at how the attribute selector is used to target specific elements enclosed within the form for the search field. Now, we'll take a look at the other components at play.

The search feature is actually one of the most complex features codewise in the entire site. As a user types a keyword query, the magnifying glass icon is replaced with a loading icon and matching results are displayed. This is sometimes referred to as live search. Both AJAX and jQuery are hard at work bringing this interaction to life. Despite the complexity, piecing the components together is easier than it seems.

First, here's a review of the markup:

<form action="#" method="get" accept-charset="utf-8">
  <fieldset>
    <legend></legend>
    <label for="search-input">Search</label>
    <input type="text" id="search-input" name="search" value="" title="Search">
    <input type="image" name="" src="img/search-go.gif">
  </fieldset>
</form>

To swap in the loading icon, the most lightweight approach I could devise—and one I haven't really seen other sites do yet either—was to combine the background image for the input field and the loading icon into a single animated GIF (see Figure 10-16). CSS is used to position the image based on the state of the interaction, shifting the image up and down as the user types to toggle between the magnifying glass icon and the loading icon.

Figure 10.16. search-bg.gif, a single animated GIF that includes two states

Here's the CSS for the input field:

#header form input[type="text"] {

...
    padding: 6px 0 0 28px;
    height: 20px;
background: url(../img/search-bg.gif) no-repeat;
    }

By default, the background image is positioned at the top left, and we restrict the height to 20 pixels. Add 6 pixels of top padding, and this means only 26 pixels of the image are shown—exactly half the height of the image. Only the magnifying glass portion is revealed.

When the user begins typing, several things happen. First, each time the user types a character, four files are engaged: autocomplete.css, jquery.plugins.js, jquery.autocomplete.js, and search.php. As typing begins, class="ac_input" is dynamically added to the input field and then removed when the live search displays results. This selector is found in autocomplete.css and is styled as follows:

.ac_loading {
background: url(../img/search-bg.gif) no-repeat 0 −26px !important;
    }

Notice the background image is now positioned −26px from the top, shifting the image upward and revealing the lower half (loading icon). This indicates to the user that data is being retrieved asynchronously from the server (search.php).

Second, while the loading icon is spinning, data is exchanged with search.php to locate results matching the characters the user is typing. Open search.php and you'll see some of the terms I've populated the file with—Ancient Ostia, Ancient Rome, Arch of Constantine, and so on.

Third, matching results are delivered back to the page, and a select-like menu is shown beneath the input field with matching results (see Figure 10-17). This menu, which is really just an unordered list (ul), is generated by a combination of jquery.autocomplete.js and jquery.plugins.js and styled by autocomplete.css. The user can then select a match with mouse or keyboard, or continue typing and press the Enter key. This completes the interaction.

Figure 10.17. The completed search feature in use

Now, jquery.autocomplete.js includes several hundred lines of code, but that's another beautiful thing about jQuery—I didn't write any of this. It's a jQuery plug-in written by the community, and many such plug-ins are available. In fact, most of the jQuery in the case study comes from plug-ins. The auto-complete one is jQuery Autocomplete and can be found at http://bassistance.de/jquery-plugins/jquery-plugin-autocomplete/.

For additional resources and tutorials, check out the following: