Welcome to another article on Building Better Web Pages. This article series comprehensively covers building an HTML document: easily learned, but rarely perfected.

Today’s article covers Separation of Presentation and Content. It is a sister article to Unobtrusive Javascript, which covers separation of behaviors and content. I recommend reading both to get the whole picture.

The purpose of this article is to discuss the pitfalls of using the style attribute and the practices that will help you create better web pages.

Solid Statement: Don’t use the style attribute in your HTML. That creates a nightmare as your webpage changes or grows. It’s a much better idea to keep all your styles organized in a separate CSS file. Not only do you know where all you presentation elements are, you can switch the whole file out on the fly and not have any problems. Additionally, avoid using presentation tags like font in your document for the same reasons.

Why Do We Use Inline Styles?

You may feel completely normal littering your HTML markup with style attributes or font tags. The funny thing is that you do this AND maintain a separate CSS file. It’s completely senseless to do so. Don’t feel bad, though: we’ve all done it. There are a few reasons people end up adding inline styles. There may be a style you need only on a single element and not every one that has that CSS class. You may be building an HTML email. However, I find myself doing it most often to make sure my style doesn’t get overridden. The style attribute will have the last word compared to the cascading styles in the external file.

Why Does it Matter?

HTML is designed to provide document structure. Style is only a concept for the human eye. The machines that read the document structure could care less about your colors and borders. In fact, you make it more difficult for those machines to understand your document structure when its full of inline styles. While the cumulative effect of this is not documented, it’s common sense. Sorting a stack of papers from the printer in the office is much easier when you know all the pages are your own. Otherwise you have to flip through them all looking for pages that belong to other coworkers first. I don’t know about you, but I prefer to make it as easy as possible for Google Bot to examine my HTML.

Aside from the search engine implications, you also have to worry about maintainability and modularity. Having inline styles means duplication of code whenever you want to copy the element that is using it. Of course, if you want to make changes later, you will have to go back and find every instance of that inline style instead of changing it once in the stylesheet. What about multiple stylesheets? Some sites allow the user to select separate stylesheets. They may offer different font settings or reverse the text and background colors. Take Gamespot for example. It’s kind of hard to offer any sort of flexibility when you created a dependency between your presentation and your content.

We should also address the em vs i and strong vs b topic. This is a hotly debated topic among designers. There is always talk about b and i being “solely for presentation” versus strong and em, which “have semantic meaning”. One good argument I heard was, “how do you render bold in an audio browser?” That seemed to be an epiphany until someone countered by asking the same question about strong. Each tag has meaning that had to be interpreted by whatever medium is accessing it. At the end of the day, b says only to make text bold and i says only to italicize text. The strong and em tags, however, allow for other interpretations. Emphasized text might mean italics in a visual web browser, pitch or tone difference in a speech browser, or different colored words in a text browser.

How to Make it Right

Some existing sites may be beyond saving as far as separation is concerned. The best strategy for any designer going forward is two-fold. The first step is to learn proper cascading. The second step is a discipline: don’t build styles on the fly. Plan out your layouts ahead of time and take advantage of proper style cascades. This will lessen the chances that you will be tempted to use inline styles. If all else fails, remember the !important rule.

If you are finding out your extensive stylesheet rules are overlapping somewhere, you can add !important to any property value to make sure it doesn’t get overridden. In the following example, we want the menu links to have a blue color. However, they keep showing up as red because of a previous declaration for div links. To make sure the new menu links are blue, we add !important after the value, but before the semicolon.

CSSview code 
div a {
    color: red;
}
 
.menu a {
  color: blue !important;
}

The Future

For years, designers have had no problem with inline styles. In fact, it is required for those of us who design HTML emails. As the web converges into a standardized bliss, designers must discipline themselves and be ready to harness its capabilities. If you weren’t interested in this concept, then you probably wouldn’t be reading this article. At times, it will be inconvenient to avoid using inline styles. It might cost you a minute or two of extra work while you add or modify a class in a stylesheet. Be proud of the fact that you will be left with 2 completely self-contained systems that can be easily maintained, scaled, exchanged, or removed.

Solid Reading

For building better web pages, any of the following books are a great! “Web Design For Dummies” introduces pretty much every aspect of design, including planning and research. If you are interested more in the concepts and ideas of proper markup, go with “HTML and CSS Web Standards Solutions”. Finally, for a more conversational tone, “Designing with Web Standards” is reading geared toward the practical application, rather than the concepts themselves.