Cascading Style Sheets

In developing standards for the World Wide Web, the W3C (World Wide Web Consortium) has proven, in their rejection of several submissions, to be aware of the need to separate content from presentation. In particular, "formatting" tags such as <FONT>, <LAYER>, and <MARQUEE> have failed to gain approval in favor of well-developed support for the Cascading Style Sheets (CSS) specification. CSS has become the accepted way to define page appearance.

While Internet Explorer 3 provided a "reference implementation" of the original CSS specification, including support for approximately 80 percent of the nonpositional CSS attributes, Internet Explorer 4 improves upon this, resulting in roughly 99 percent compliance. There are just a few attributes of the CSS specification unimplemented in Internet Explorer 4. Among these unsupported attributes are some of the CSS pseudoclasses (first-line and first-character), and interword spacing. You can specify these attributes, pseudoclasses, and values; however, Internet Explorer 4 will ignore them. Oddly enough, there are technically unsupportable attributes in the specification. For example, how would one implement a vertical alignment of center when parsers are not allowed to "look ahead" to see where the next element might be?

Controlling Page Appearance

DHTML provides a number of ways to control the appearance of a page. You can position the page, use filters on text elements, and take advantage of many other features to enhance the user's experience.

It's a big deal in the HTML world to be able to specify absolute positioning. However, application designers have been able to do this for years. Absolute positioning, however, goes beyond the traditional x and y placement. There are also positioning modes that allow relative location on the page as well as allowing reflow, floats, and keeps (taken from the document-oriented nature of HTML).

The Visibility, Display, and Z-index attributes are three useful positioning characteristics. The Visibility attribute determines whether an element is visible. The Display attribute controls whether the item still takes up space in the document according to its actual (though invisible) size. When set to "none," it removes the item and its allotted space from the document, causing all items later in the document to reflow to fill the item's space. The Z-index attribute specifies the relative depth of elements on the page. This is particularly useful with absolutely positioned items.

Using Microsoft WEFT (Web Embedding Fonts Tool), which is available from Microsoft's typography group, we can create "font objects" that we can download with our pages. These font objects are installed privately: only Internet Explorer can use them, and then only in the context of the site for which they were defined. See http://www.microsoft.com/opentype/free.htm for more information and to download WEFT and other utilities.

We can specify typeface, size, family, color, and special treatments (small caps, for example). Using filters, we can also rotate, illuminate, and make masks from our text elements.

Maintenance and Performance

One of the simple advantages of using style sheets is the fact that, since style information is separate from the document (in most cases, anyway) we can use the style information in many contexts. This is great, because developing a good style sheet is no trivial task, and it is important to be able to gain as much reusability as possible. As the shared style sheet changes, documents that use the style sheet do not need to be changed. Hits to the client documents of a style sheet will reflect the changed styles—no recompilation or relinking required.

There are thousands upon thousands of graphics that are simply words formatted in a pretty way. The capabilities introduced with style sheets allow many of those graphics to be replaced with smaller, faster-to-download text.

A side benefit of using a global style sheet for many pages in an application is that the style information goes down to the client machine once. This cached style sheet will be referenced on all client pages, further reducing the download costs of using style sheets.

There's just a whole lot less coding when using style sheets than there is with one-off formatting of each and every paragraph. Within a document, many paragraphs will typically receive common treatment. By using style definitions, you simply point to a rule and your information is formatted by that rule. If you want an exception to the rule—no problem.

In a well-designed document, all of the style information is moved out to the style sheet. This substantially reduces clutter, leaving only content. You will rarely need to mix style information with content.

When working in multiple media, you can use different styles for each medium. For example, you might make the printable set of styles active when you want to print a document designed primarily for online presentation. By removing the formatting from the content, you can more easily repurpose the information.

No more pesky font tags or tables in tables in tables—or any of those weird tagging arrangements once used to get a special effect on the page. All has been reduced to declarative "put-it-right-here, just-like-this" language.

Linked-In Style Sheets

Linked-in style sheets form the most reusable style information you can get. The style sheet is a stand-alone document of MIME-type text that can be referenced by multitudes of individual pages.

There are two ways to reference external style sheets—using the <LINK> tag or using the @import statement inside a <STYLE></STYLE> block. Generally, you link the primary style sheet in, and @import other supporting style sheets from within that linked-in main style sheet.

Whether you use <LINK> or @import, you can give each style block a separate name. Why would you bother to do this? Because at run time you can turn whole style sheets on or off with a single statement. That's a pretty powerful tool. For example, with external style sheets, we can implement separate online and print versions of a document within a single file. To print the document, we simply turn off the online styles and turn on the styles suitable for printing.

You can import a style sheet by using @import:

 <STYLE>     @import url(http://www.32x.com/ie4sem/styles/primary.asp); </STYLE> 

The next example uses the <LINK> tag:

 <HTML> <HEAD><LINK REL="stylesheet" TYPE="text/css"      HREF="_Themes/expeditn/COLOR0.CSS" VI6.0THEME="Expedition"> </HEAD> 

Embedded Style Sheets

While you're experimenting with presentation, it might be easier to have the style information in a style block right there in your test document. You can move the information into a separate style sheet at any time. The advent of the CSS editor in Visual InterDev 6.0 makes working with separate style sheets easier.

Suppose all your documents share a global style sheet. Usually the definitions in the global style sheet satisfy 95 percent of each document's requirements. You can satisfy the other 5 percent by defining an embedded style sheet, which is a style block local to the document. An embedded style sheet fits the bill until the global style sheet can incorporate the needed additions.

You might find that some styles are too document-specific to include in the global style sheet. In these cases, an embedded style sheet might be the trick. However, remember that you can reference multiple style sheets. The last one overrides the earlier ones, so at some point it still might be advantageous to separate the embedded style sheet out into a separate file.

To add an embedded style sheet, simply add a <STYLE></STYLE> pair inside the <HEAD> section of your document. Technically, you could add an embedded style sheet to the <BODY> section as well, but the recommendation is to add it in the <HEAD>. Place your style definitions, one to a line, inside the <STYLE> block.

Using the CSS Editor

The CSS Editor allows you to edit style sheets by selecting properties in a set of property pages. This graphical interface makes it easy to create and modify style sheets. Figure 7-10 shows the CSS Editor in the center of the Visual InterDev development environment. To add a style sheet to your Web project and invoke the CSS Editor, simply select Add Item from the Project menu and then double-click Style Sheet in the Add Item dialog box. In the left part of the CSS Editor window, you can see the style sheet outline, which displays the tags and classes in the style sheet. You can use this outline view to move around in the style sheet. When you click a tag or a class in the outline, the CSS Editor updates the display of the property pages to reflect the current settings of the item you selected.

Figure 7-10. The CSS Editor.

Table 7-2 contains descriptions of the CSS Editor property pages.

Table 7-2. CSS Editor property pages.

Page	Description
Font	Controls the font aspects of the current style or class.
Background	Changes background properties. This is handy when you need to use an image for the page background. You can set the image file name, specify how to tile the image, and in general control the image's formatting. This is much easier than trying to remember the individual attributes to make these changes.
Borders	Changes border properties. The Borders page makes setting borders a quick and easy process. You can choose the border style, set the margins and padding, and control the border's color.
Layout	Changes layout properties. This page is useful for controlling layout features such as spacing between characters or page breaks.
Lists	Controls list characteristics. This page makes setting up list features a snap. You can control the type of list, the type of bullets used for the list, and the location of the bullets.
Advanced	Controls positioning and other advanced properties. You can control the clipping rectangle and you can control whether the item is visible.
Source	Displays the source for the style sheet.
Preview	Previews the style sheet.

The Preview page demonstrates how a page will look when rendered with your style sheet. Figure 7-11 shows the Preview page.

The Preview page simplifies style testing by providing on-demand previews. You can use this page at the click of a button to display almost any feature of the style sheet you are working on. You can also change the page that is used for the preview.

By unchecking the Style Sheet Applied check box, you can toggle between viewing the page with and without your style sheet.

Figure 7-11. The CSS Editor Preview page.

Style Information on the Tag

Most of the time, positioning information is one-off. That is, you want a particular element placed in a particular location, and you don't want to make any general rules about the placement. In such cases, it's perfectly appropriate to specify style information directly on the tag.

In fact, certain attributes don't work unless they're directly on the tag. For example, the Background-image attribute no longer works in the style definition. It must be specified on the tag! As it turns out, this is true of every style attribute that implicitly creates a multimedia object to control the attribute, such as background image characteristics and filter attributes.

Style information attached to a tag is also appropriate for any "ad hoc" style data. Again, at the times when you need very specific one-off control, this method allows for that fine-grained control.

Just as the embedded style sheet overrode the linked-in style, the on-tag style information overrides both the embedded and the linked-in style definitions. However, there is an exception. If a style rule is declared as important (we'll see this later when we talk about style rules), it can override even in-tag style information regardless of where it is defined.

Don't get carried away with in-tag styles! They'll wreak havoc on your attempts to define more global style information later. In-tag styles also muddy up the well-separated relationship between style sheets and the content, potentially rendering your document less portable.

It's easy to define style information on the tag: just put a Style attribute on the tag. Every Visible tag supports the Style attribute.

Defining Style Rules

Rules specified in linked-in style sheets or in embedded style sheets have the same syntax. There is a rule scope followed by the rule itself, which looks like this:

 rule-scope  {attribute:value;attribute:value;...} 

You can specify as many attribute-value pairs as you want in a style rule. The braces, colons, and semicolons are required. (Technically, the last semicolon isn't required, but it does make cutting and pasting attribute-value pairs less error-prone.)

Rules specified on tags do not require a scope because the rule is implicitly the duration of the tag itself. This can, depending on the inheritance of the specified rule, also apply to any elements coded within the bounds of block elements. So, in-tag rules look like this:

 <SOMETAG STYLE="attribute:value;attribute:value;..."> 

Any visual tag can have a Style attribute, although not all rules are valid for all tags.

Specifying the rule's scope

Rules that are more specific have precedence over less specific rules. That's why the in-tag styles override the style-sheet-defined rules. When we define style rules we can define various scopes. For example, we can define how all text in the document looks, and then we can make specific exceptions based on tag, class, or on an individual basis. This is a typical way to work—first define general rules, and then the finer scope defines exceptions to those rules.

You can define a single set of rules that applies to as many scopes as you want. Just separate the scopes with commas:

 s1, s2, s3  {attribute:value;attribute:value;...} 

The tag scope is the most general, least specific scope, and can therefore be easily overridden or augmented in later style rules. Some tags have broader scope than others do. For example, the <BODY> tag contains all other visible tags in a document, and therefore has the broadest style scope. Consider the following:

 body        {font-family:arial;font-size:10;} p           {font-size:9;} 

In the example above, the <P> tag inherits its font family from the <BODY> tag's rule but overrides the font size rule.

You can define rules that apply to a broad range of elements. Rules defined by class can even span different tags, since the same class can be applied to many different elements regardless of tag. You use a period (.) to indicate a class rule:

 .error      {font-color:red;} 

Specifying a rule by class is convenient but implies that many tags in the document can end up with Class attributes on them. While not a huge maintenance burden, this can be tedious. There is a way to specify how things will look when they're contained inside another scope. For example, the following rule indicates how a paragraph will look when it is inside a <DIV> of class Error:

 div.error p {font-color:red} 

Now all the paragraphs inside an Error section will share this characteristic without requiring individual Class attributes specified.

You can define a rule for all elements that share an ID. Technically, IDs are supposed to be unique, which implies that the rule applies to a single item. This might sound like a ridiculous scope, but it's actually quite valuable.

Setting Style Attributes

Attribute-value pairs don't all need to be specified on the same line. CSS uses curly braces ({ }) to determine where a rule starts and ends, and the semicolon (;) to separate attribute-value pairs. So use as much space as is helpful to make your style sheets readable.

Font size, family, weight, and style

A large portion of a typical style specification concerns itself with the fonts of various elements in the document. You can control the significant characteristics of the font using the following properties:

 font-family font-size font-weight font-style font-variant @font-face 

A couple of notes on these attributes:

• When specifying the family name, use quotes around the name. It's required if the name has embedded blanks (and it's a good idea anyway).
• The @font-face attribute is used to name a "font object" that you've defined with the font-object creation tool.

Margins, spacing, and positions

You can also control the relative spacing of elements as they appear on the page. The most commonly used attributes are:

 margin derivatives (margin, margin-left, etc.) left top width height position display 

With Internet Explorer 4.0, we now have onresize events. We can use onresize to implement a layout policy for items on the page. This is the standard procedure in application environments such as Microsoft Visual Basic. However, a more robust and easier to develop approach is to use percentage-based values for the placement attributes.

Colors, borders, and special effects

We have a rich set of attributes to control the colors, border styles, and special-effect filters for each element. Note, however, that filters and borders only work for block elements (those elements that essentially form their own separate paragraphs). Block elements imply a line break at the beginning and end of the element.

Miscellaneous page characteristics

With HTML-only browsers, we had the attributes on the <BODY> tag to control the background color and image displayed behind the document. For DHTML browsers you can still do this, but the preferred method is to use the background-management attributes on the Style attribute of the <BODY> tag. In fact, you can do this for any block element.

Differences in Netscape Navigator and Internet Explorer

Netscape Navigator and Communicator versions 4.0 through 4.03 implement cascading style sheets in a different manner than Internet Explorer. Navigator and Communicator treat relative URLs in style sheets as relative to the document they are referenced in, instead of relative to the linked-in style sheet. You should edit the CSS files and change the relative links to absolute links to work around this problem.