To inline or not to inline

As every web developer knows, there are three ways to apply CSS styles to a document. One can use a separate style sheet in connection with the <link> tag, one can embed style definition block(s) directly in the HTML document, or one can inline CSS using the style attribute with single HTML tags. These three approaches represent different (descending) levels of separation. The last method, inline CSS, is somewhat peculiar, because it appears to defeat the principle that CSS is founded upon, namely the separation of content of presentation. After all, writing something like <span style=”font-style: bold”>something</span> ist just another -more cumbersome- way of writing <b>something<b>.

Hence, the question arises: why use inline CSS at all? The naive understanding is that only external style sheets are “good” and that inline CSS and embedded CSS styles are “bad”. But this criticism raises the question: why did the designers of CSS provide for the possibility of inline styles if it was evil to begin with? Are CSS inline styles the equivalent of the infamous “goto” command?

The truth is that, despite the overarching goal of high level of abstraction and presentation separation, there are some legitimate uses for inline styles. To be precise, there are two such cases. First, inline CSS is appropriate when the default styling, as specified by one or more style sheets, needs to be overridden in specific instances. Second, inline CSS is appropriate for micro-styling issues. The first use case is easy to understand. For example, you have all your links defined to be blue and non-underlined using the appropriate definitions in a style sheet. There is one point, however, where you want the link to be green rather than blue. Use an inline style in this case.

The other case requires some explanation, and to be frank, some experience in web design as well. What I have called micro-styling issues are layout issues related to the specific sequence of HTML, text, and images in a given document. These are instance-specific issues that don’t repeat. The vast majority -probably over 90%- of these issues concern spacing and text flow. A typical example would be to adjust the vertical and horizontal spacing between adjacent elements using the float, margin, and padding styles. A somewhat less typical example would be setting the width of columns or text paragraphs in specific instances, or make the corners of an outlined box rounded using CSS 3 styles.

In summary, inline CSS is appropriate wherever styling is specific to the element. This could be the case if default styles must be overridden or if custom layouts require micro-styling. However, if you find yourself repeating the same style tags in different places, something is going wrong. Stop and refactor! Withstand the copy-paste coding temptation. It is easy to generate code that way, but very hard to maintain. Create classes or appropriate selectors instead and move the definitions to an external style sheet.

Let’s look at a typical border case. Say, we use divs to contain form elements in our web application in order to arrange form controls and labels into columns and rows. Typical micro-styling issues, such as managing white space between specific columns can be solved with inline CSS. If we find that certain spacing definitions repeat, for example if we want all form rows to have a five pixel bottom padding, then this situation would call for a CSS style sheet definition.

The quintessence is: the DRY principle also applies to CSS. While the overall goals of CSS are separation of content and presentation, abstraction, and ease of maintenance, and while the use of inline CSS generally counters these goals, inline CSS is appropriate for the mentioned purposes. It takes a bit of experience to know when it’s OK to break the rules and when it is not.