• Choose a category
• All
• Classic-Fiction

If you’re writing a program to translate from a word processor or other tool, local styles are often the easiest way to make the translation work. If you use a word processor to create a page and you tell it to save the page as HTML, it will often use local styles because word processors often use this technique in their own proprietary format. Usually when you see an HTML page with a lot of local styles, it’s because an automatic translation tool made the page.

Sometimes, you see local styles used in code examples. For example, the following code could be used to demonstrate different border styles:

“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>

Inline Borders

This paragraph has a solid black border

This paragraph has a double black border

For example purposes, it’s helpful to see the style right next to the element. This code would be fine for demonstration or testing purposes (if you just want to get a quick look at some border styles), but it wouldn’t be a good idea for production code.

Local styles have very high priority, so anything you apply in a local style overrides the other style rules. This can be a useful workaround if things aren’t working like you expect, but it’s better to get your styles working correctly than to rely on a workaround.

The other place you’ll occasionally see local styles is in Dynamic HTML (DHTML) applications, such as animation and motion. This technique often involves writing JavaScript code to change various style elements on the fly. The technique is more reliable when the style elements in question are defined locally. See Book IV, Chapter 7 for a complete discussion of this topic.

The drawbacks of local styles

It’s pretty easy to apply a local style, but for the most part, the technique isn’t usually recommended because it has some problems, such as:

♦ Inefficiency: If you define styles at the element level with the style attribute, you’re defining only the particular instance. If you want to set paragraph colors for your whole page this way, you’ll end up writing a lot of style rules.

♦ Readability: If style information is interspersed throughout the page, it’s much more difficult to find and modify than if it’s centrally located in the header (or in an external document, as you’ll see shortly).

♦ Lack of separation: Placing the styles at the element level defeats the goal of separating content from style. It becomes much more difficult to make changes, and the mixing of style and content makes your code harder to read and modify.

♦ Awkwardness: An entire batch of CSS rules has to be stuffed into a single HTML attribute with a pair of quotes. This can be tricky to read because you have CSS integrated directly into the flow of HTML.

♦ Quote problems: The XHTML attribute requires quotes, and some CSS elements also require quotes (font families with spaces in them, for example). Having multiple levels of quotes in a single element is a recipe for trouble.

Using an external style sheet

CSS supports another way to use styles, called external style sheets. This technique allows you to define a style sheet as a separate document and import it into your Web pages. To see why this might be attractive, take a look at the following figure.

Figure 5-2 shows a page with a distinctive style.

Figure 5-2: This page has styles for the body, h1, and paragraph tags.

When you look at the code for externalStyle.html, you might be surprised to see no obvious style information at all!

“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd