With a better grip on some of the more clever points in our style sheet (as if that says much), we could easily paste this entire chunk of code into a <style type=“text/css”>…</style> block in the head of our document. Of course, that would muddy our markup with presentational information—and honestly, who wants to hunt down style information across a few hundred XHTML documents? That’s right, some call it “adhering to a strict separation between structure and style.” We call it “lazy.”

In either event, let’s create a second style sheet, and name it main.css; at the top of that new file, we’ll use the @import command to invoke our core.css file, like so:

@import url("core.css");

We’ve effectively created a “wrapper” style sheet—a CSS file that acts as a gateway to other style sheets. With this main.css file in hand, we can now include it—and with it, core.css—in our XHTML with one simple link element, placed in the head of our document:

<link rel="stylesheet" class="main.css" type="text/css" />

And voilà! Our rather plain-looking document suddenly gets a bit of personality in Figure 8-2.

Figure 8-2: Applying some basic styles to our XHTML makes it a bit more readable.

After creating this seemingly superfluous main.css file, there might be some head-scratching in the audience. But rest assured, there are some very good reasons for putting this file in place. Although it wasn’t designed as such, the @import rule is a kind of litmus test for a browser’s support of advanced CSS techniques. Legacy browsers that have broken CSS implementations don’t understand the @import rule, and will simply disregard it. This allows us to serve up high-octane style sheet rules to modern browsers, while such antiquated browsers as versions 4 and below of Netscape and Internet Explorer will simply ignore the style sheets that they wouldn’t otherwise understand.

An added benefit to this intermediary style sheet is that we can place multiple @import rules therein. This could come in handy if we needed to break our site’s presentation into multiple files (for example, one for layout, another for color, yet another for typography). Or even better, we can use this technique to manage our various CSS hacks, as we saw in Chapter 2. As you test the CSS in Listing 8-3, you may find that the different versions of Internet Explorer (both on the Macintosh and Windows platforms) break different aspects of the layout. While we could use a battery of style sheet hacks within our core.css file to serve up alternate property values to these browsers’ broken CSS implementations, Listing 8-3 shows how we might use our wrapper style sheet to include browser-specific CSS hack files, which allow us to keep our main.css file clean and hack-free.

Listing 8-3: A Revised core.css File, with Intelligent Hack Management

@import url("core.css");

/* Import WinIEx-only bugs - hide from Mac IE5 \*/
@import url("hacks.win.iex.css");
/* END hide from Mac IE5 */

/* Import Win IE5x hacks */
@media tty {
     i{content:"\";/*" "*/}} @import 'hacks.win.ie5.css'; /*";}
}/* */

/* Import Mac IE5 hacks */
/*\*//*/
@import url("hacks.mac.ie5.css");
/**/

We’ve already discussed the CSS hacks needed to get our page looking good in less-than–CSS-savvy browsers, and triaging the different hacks into browser-specific files is an excellent way to keep our core.css file clean and hack-free. If we ever decide to drop support for a certain browser, we now need to remove only a few lines from main.css—definitely a more appealing thought than scouring our primary style sheet rules line by line, looking for CSS hacks. Again, it’s equal parts “strategic” and “lazy” here at CSS Best Practices Headquarters.

Now that we’ve put our CSS and XHTML firmly in place, we can delve into the mechanics of style sheet switching.

CSS Switching

One fault of our page’s current design is that legibility wasn’t one of our guiding design goals. The contrast is a bit light, as we opted to use a near-black color for the text against the body’s white background. And the default font size of 62.5 percent of the browser’s default (or roughly 10 pixels) might be difficult to read for users suffering from visual impairments. (Even a reader with slight myopia might have to work at reading our content.) How can we improve the design to make it more legible, without sacrificing our original vision?

To begin, let’s create a separate style sheet that addresses some of these possible pitfalls. In Listing 8-4, we’ve created a new CSS file named contrast.css.

Listing 8-4: The contrast.css Style Sheet

body {
  background: #000;
  color: #DDD;
}

h1, h2 {
  color: #FFF;
  font-weight: bold;
}

#content {
  .1em;
}

#content h2 {
  .6em;
  text-transform: none;
}

#content #blurb {
  background: #222;
  border-color: #444;
  color: #FF9;
}

span.lead {
  font-weight: bold;
}

Now let’s simply add a link to our new contrast.css file in the head of our markup, like so:

<link rel="stylesheet" class="main.css" type="text/css" /> 
<link rel="stylesheet" class="contrast.css" type="text/css" />

When we reload the document in our browser, Figure 8-3 shows us that the landscape has changed pretty drastically.

Figure 8-3: Now we’re on our way, as we’ve added a supplementary style sheet that provides heightened contrast and an increased font size.

First and foremost, it’s worth mentioning that because the two CSS files are being included in tandem, we don’t need to use contrast.css (Listing 8-4) to re-declare any of the layout or type rules established in main.css. Rather, we can simply selectively override individual rules and/or property values, and let the rules of specificity handle which rules cascade to the user.

From a purely aesthetic point, we’ve instantaneously changed the presentation of our markup—and all by including the new contrast.css file. The off-black text has been replaced with pure white, the text size has been increased very slightly (from 1em to 1.1em), and the colors on our pull quote have been changed to reflect the new palette. The completed effect feels much more nocturnal—but more important, we’ve created a style sheet that allows users to enjoy a higher level of contrast, as well as a slightly more legible type size.

But we’ve still not settled our original problem. How do we switch between the two style sheets? We grew pretty attached to that white, open design—it would be a real shame to lose it, wouldn’t it?

Oh, at least pretend it’s pretty. Please?

The Mechanics: How It’s Supposed to Work

Thus far, we’ve associated two separate CSS files with one document. Currently, they’re both being read and applied to the document with equal weight, with the rules of specificity resolving any conflicts that may arise between the two. However, to accommodate more complex scenarios than the one we currently have, the HTML and CSS specifications outline structured guidelines for how multiple style sheets interact. Web page authors are given a number of ways to prioritize the style sheets we include via the link element. Let’s examine the three different classes of style sheets (no pun intended), and see how they might apply to our switching scenario.

Persistent Style Sheets

Persistent style sheets are always enabled. Think of them as CSS that is “turned on” by default. The persistent CSS file will be applied in addition to any other style sheets that are currently active, and acts as a set of shared style rules that every other style sheet in the document can draw upon.

Each link element with a rel attribute set to “stylesheet” is a persistent style sheet—and, in fact, we’ve created two already:

<link rel="stylesheet" class="main.css" type="text/css" />
<link rel="stylesheet" class="contrast.css" type="text/css" />

As we add additional kinds of style sheets, any links that we designate as persistent will act as the baseline, sharing their rules with all other included CSS files.

Preferred Style Sheets

By adding a title to a persistent style sheet, we can designate a style sheet as preferred, like so:

<link rel="stylesheet" class="main.css" type="text/css" /> 
<link rel="stylesheet" title="Higher Contrast" class="contrast.css" type="text/css" />

Additionally, we can specify multiple “groups” of preferred style sheets by giving them the same title attribute. This allows the user to activate (or deactivate) these groups of CSS files together. Should more than one group be present, the first group will take precedence.

Much as with persistent style sheets, preferred CSS files are enabled by default. So, in the previous example, our contrast.css file (refer to Listing 8-4) would be enabled when the user first visits our page (borrowing, as it did before, from our persistent main.css file). However, preferred style sheets are disabled if the user selects an alternate style sheet.

Alternate Style Sheets

An alternate style sheet can be selected by the user as, well, alternatives to a CSS file marked as preferred by the site’s author. To designate a link as an alternate style sheet, it must be named with a title attribute, and its rel attribute set to “alternate stylesheet”. As with preferred style sheets, we can group links together by giving them identical title attributes. So, in short, this is what we’ve been looking for—a means through which we can allow users to select the design that best suits their needs. If we do, in fact, want main.css to be the default and contrast.css to be an optional, alternate CSS file, then we should update our two link elements to match:

<link rel="stylesheet" class="main.css" type="text/css" />
<link rel="alternate stylesheet" title="Higher Contrast" class="contrast.css" type="text/css" />

Now, viewing the page in a browser that supports style sheet switching, the user can finally control the display of the page. Browsers such as Firefox or Opera include an option to select our new alternate style sheet, as shown in Figure 8-4.

Figure 8-4: By changing the rel attribute of the second link element to “alternate stylesheet” and supplying a title, we’ve implemented some basic style switching.

Once the user selects Higher Contrast from the menu, the alternate style sheet with that title—namely, contrast.css—becomes active. So, we’ve finally settled on the solution we were looking for. Our original design is the active default, but we’ve created the means through which users can select another design altogether. Using this method, we can add even more alternate CSS options. Let’s create a file named hot.css and use the rules in Listing 8-5.

Listing 8-5: The hot.css Style Sheet

body {
  background: #000 url("bg-stylish.jpg") no-repeat 50% 0;
  color: #DDD;
}

h1, h2 {
  color: #FFF;
  font-weight: normal;
  text-align: center;
  text-transform: none;
}

#content {
  .1em;
}

#content h1 {
  font: 2.6em Zapfino, "Gill Sans", Gill, Palatino, "Times New Roman", Times, serif;
  margin: 200px 0 70px;
}

#content h2 {
  font: 1.6em "Gill Sans", Gill, Palatino, "Times New Roman", Times, serif;
  margin: 1.4em 0;
  text-transform: uppercase;
}

#content #blurb {
  background: #222;
  border-color: #444;
  color: #FF9;
}

span.lead {
  font-weight: bold;
}

And now, by applying what we’ve learned about alternate style sheets thus far, we can easily present hot.css (refer to Listing 8-5) to our users as another user interface option:

<link rel="stylesheet" class="main.css" type="text/css" />
<link rel="alternate stylesheet" title="Higher Contrast" class="contrast.css" type="text/css" />
<link rel="alternate stylesheet" title="Gratuitous CSS" class="hot.css" type="text/css" />

If our users have the ability to select another alternate CSS file from their browsers, then they’ll be able to see our new styles as shown in Figure 8-5. And, as before, the change is a fairly drastic one—but we’ve finally allowed the users to choose an appealing design and tailor our content to meet their needs.

Figure 8-5: With our understanding of how the cascade works, we can build even more complexity into our alternate CSS documents.

Another Solution We (Almost) Can’t Quite Use

As with some of the most promising features of CSS, adoption of alternate style sheets would be more widespread if browser support were more robust. As of this writing, the number of browsers that natively allow users to select alternate style sheets is limited to Gecko-based browsers such as Mozilla or Firefox, and the Opera browser. For example, Apple’s Safari has no way to select alternate or preferred style sheets. And, you guessed it, Internet Explorer (the browser known and loved the world over) won’t allow users to select the alternate user interfaces we build for them. If the world’s most popular browser keeps this feature out of the hands of our users, then we have a bit more work to do yet.

Furthermore, the browsers that do natively support alternate style sheet switching have only a limited switching functionality. While these browsers do allow the user to easily switch between the default CSS and any alternates provided by the author, they do not remember the user’s selection. This means that, if a reader selects an alternate style sheet and then reloads the page or leaves and returns to it, the browser will forget the earlier choice and reinstate the default style.

Obviously, neither of these scenarios will work for our users. We’re lucky that there are some additional steps we can take to bring the full benefits of CSS switching to them.

The Reality: How It Can Work Today

We’ve established that most of our audience won’t be able to use in-browser CSS switching (and identified those who don’t have much functionality available to them) so we must build an interface into our page that allows users to overcome these limitations. Now, you might realize that the two client-side technologies we’ve been studying up to this point aren’t especially well equipped to handle this. While XHTML and CSS excel at describing and styling content, respectively, neither was designed to interact with the user. Sure, we can use XHTML to build a list of links on the page as follows:

<div id="switcher">
  <ul>
    <li id="style-default"><a class="styleswitch.html">Default style</a></li>
    <li id="style-contrast"><a class="styleswitch.html">Higher Contrast</a></li>
    <li id="style-hot"><a class="styleswitch.html">Gratuitous CSS</a></li>
  </ul>
</div>

And we can add some CSS to core.css (refer to Listing 8-2) to style them accordingly, as shown in Figure 8-6:

/* switcher styles */
#switcher ul {
  text-align: right;
  list-style: none;
}

#switcher ul li {
  border-left: 1px solid;
  list-style: none;
  display: inline;
  padding: 0 0 0 1em;
  margin: 0 1em 0 0;
}

#switcher #style-default {
  border-left: 0;
  padding-left: 0;
}

#switcher ul a.now {
  color: #000;
  font-weight: bold;
  text-decoration: none;
}
/* END switcher styles */

Figure 8-6: We’ve added the links for our switcher to the top of our page, but all they can do at the moment is look pretty—and we’re about to change that.

However, what happens when the user clicks on those links? If your answer was something akin to “zilch,” then you win the blue ribbon. XHTML and CSS can’t really do anything when you’re talking about responding to a user’s actions. They can, in turn, affect the content and the presentation of the page, but when the user tries to click a link to change the active style sheet, that’s where we need to turn to the third tool in the standards-savvy designer’s toolkit: JavaScript.

Jumping on the JavaScript Bandwagon

To put it simply, JavaScript was created as a client-side scripting language. JavaScript (or JS, to use the parlance of lazy typists everywhere) is a language designed to add a layer of interactivity into our Web pages. When a user visits a Web page that has some JavaScript code in it, the browser reads the JS, and then follows any instructions that might be contained therein. Those instructions might tell the browser to display helpful messages to a user as he or she completes a form, or to perform basic validation on the data he or she enters there. We can even use JS to instruct the browser to perform a certain action when the user clicks a link. In short, JavaScript is the means through which we bridge the divide between our content and our users, allowing the latter to fully interact with the former.

Sounds intimidating (and more than a little stuffy), doesn’t it? Perhaps it’d be best to just dive right in.

Gathering Requirements

Before we begin a lick of coding, we should make sure that we understand exactly what it is that we’re building. Just as we discussed the benefits of requirements gathering to a client project in Chapter 1, the smallest development gig can benefit from some sort of needs analysis. With a better understanding of what we need to build and the goals it should achieve, we can code more quickly and efficiently—two qualities that will make our clients and us quite happy.

So let’s take a quick inventory of what we’re working with:

• We have three link elements in the head of our XHTML document that include screen-specific CSS files: a persistent style sheet (main.css), and two alternate style sheets (contrast.css in Listing 8-4 and the ultra-swank hot.css in Listing 8-5).
• Accordingly, at the top of our document we’ve created a list of three anchors, each corresponding to a different style sheets. Granted, these anchors are about as useful as a road map in the desert, but we’re going to change that shortly.

With this in mind, what exactly should our function do? Ideally, when a user clicks a link:

1. The function should cycle through each of the link elements in the head of our XHTML, and inspect those that link to style sheets and have a title.
2. If the link matches the link that the user selected, then it should be set to be the “active” CSS.
3. Otherwise, the link should be set to “disabled,” which will prevent the browser from loading the style sheet.
4. Once the function has finished setting the active link element, it should remember the user’s choice. The style sheet the user selected will, therefore, remain “active” as the user browses through the site, and the choice will be remembered if the user returns to our site during a later browsing session.

How, you may ask, will we do all of this? Well, the solution ultimately involves a fair amount of pixie dust and happy thoughts—but we shouldn’t get too far ahead of ourselves.

Building the Switching Function

With our goals firmly in mind, we can begin building our style sheet functions. Let’s create a new file called scripts.js, and include the following markup in the head of our XHTML document:

<script type="text/javascript" src="/img/spacer.gif"> 

// activeCSS: Set the active stylesheet
function activeCSS(title) {
  var i, oneLink;
  for (i = 0; (oneLink = document.getElementsByTagName("link")[i]); i++) {
    if (oneLink.getAttribute("title") && findWord("stylesheet", oneLink.getAttribute("rel"))) {
      oneLink.disabled = true;
      if (oneLink.getAttribute("title") == title) {
        oneLink.disabled = false;
      }
    }
  }
}

// findWord: Used to find a full word (needle) in a string (haystack)
function findWord(needle, haystack) {
  return haystack.match(needle + "\\b");
}

<div id="switcher"> 
 <ul>
  <li id="style-default"><a class="styleswitch.html">>Default style</a></li>
  <li id="style-contrast"><a class="styleswitch.html">>Higher Contrast</a></li>
<li id="style-hot"><a class="styleswitch.html">>Gratuitous CSS</a></li>
 </ul>
</div>

// Set the cookie 
function setCookie(name,value,days) {
 if (days) {
   var date = new Date();
   date.setTime(date.getTime()+(days*24*60*60*1000));
   var expires = ";expires="+date.toGMTString();
 } else {
   expires = "";
 }
 document.cookie = name+"="+value+expires+";";
}

// Set the active stylesheet
function activeCSS(title) {
  var i, oneLink;
  for (i = 0; (oneLink = document.getElementsByTagName("link")[i]); i++) {
    if (oneLink.getAttribute("title") && findWord("stylesheet", oneLink.getAttribute("rel"))) {
 oneLink.disabled = true;
      if (oneLink.getAttribute("title") == title) {
         oneLink.disabled = false;
      }
    }
 }
 setCookie("mystyle", title, 365);
}