Ask a UI Guy: What’s so bad about inline styles?

Brian Dillard, Monday, December 8, 2008 @ 2:41 pm

Welcome to "Ask a UI Guy," an occasional new feature in which we tackle JavaScript, markup and CSS questions for an audience of server-side developers. Today's topic: the deceptive allure and subtle peril of inline styles.

When you're first cobbling together a new feature or content page, inline styles can seem like a great idea. You're already editing an ERB, JSP, PHP or ASP template, so why not just write your CSS code in the same file? Throw a few style attributes into your HTML tags, populate them, and voila: instant look-and-feel.

What seems good in theory, however, quickly falls apart in practice. Many seasoned CSS developers employ external stylesheets for even the most roughshod of skunkworks. They do so with a fervor approaching that of TDD adherents carefully writing tests before even thinking about tackling actual code. People have been arguing against the use of inline styles in production code for close to a decade now, but I argue against their use at any stage of a project. Here are some of the reasons why:

1. Inline styles break the look and feel of your site: If every page gets styled in isolation, it's difficult to achieve a uniform look and feel. Small differences in the inline styles of different components will accumulate over time, creating a look that's either subtly or dramatically "off."
2. Inline styles are unmaintainable, turning even small site-wide design tweaks into huge chores: The promise of CSS is that you can re-skin your site without ever editing a single piece of markup. That's true - as long as you don't utilize inline styles. When your design director decides your site needs more white space, it'll be a royal pain to find every element with an inline padding declaration. Let's hope your RegEx skills are up to snuff.
3. Once you've written inline styles, you'll forget to move them to an external stylesheet: Most folks know styles should eventually live in an external stylesheet. Those who employ inline styles think they're doing so on a temporary basis. But let's face it, once you've got something working, how likely are you to carefully cut, past and reformat a bunch of code to a new location and file format just to satisfy an abstract ideal such as "all styles belong in an external stylesheet"? We all start coding with the best of intentions, but real life intervenes. If you never put those styles inline to begin with, you'll never have to move them - or feel guilty months later when you come across your code and realize they're still stranded inside style attributes.
4. If you do move your styles, you'll have to come up with the proper selectors: With inline styles, you don't need to write selectors, just rules. The tag in which your rules are declared is the selector. Once you move the styles, you'll have to examine your markup to figure out how best to target that element. Will you add a class? Add an id? Declare your styles on the base HTML element itself? It's no fun having to think about that hours or days after you wrote the rules themselves.
5. CSS rules won't work the same once you move them to an external stylesheet: CSS stands for "Cascading Stylesheets." The cascade is determined by not only the type of declaration, but also the location of the declaration. Inline styles trump rules in external stylesheets. Assuming you actually do eventually move your inline styles to an external stylesheet, you'll almost certainly have to tweak them to get them to work with the new cascade weight they carry in their final location.
6. Inline styles are confusing to debug: When you're working on an existing application with well-established and -populated external stylesheets, your use of inline styles can generate cascade confusion. Individual elements will be controlled by both inline and external styles. Sure, Firebug can tell you which rules are affecting which elements at any given time, but the mixture still makes it harder to debug a visual issue.
7. Inline styles violate the DRY principle: You can't create compound declarations with inline styles. You can't, for instance, use a single rule to cause all p children of div#whatever to have a padding of 5px and a left float. Instead, you have to include those rules in the style attribute of each individual p element. When and if you actually move these styles to a stylesheet, they'll either be horribly inefficient or you'll have to rewrite them. Either way, that's a lot of extra typing. And of course, as long as the styles remain inline, if you want to change how three sibling p elements look, you'll have to change your rules in three places. Invariably you'll remove, say, a float: left from two of them but not the third, then scratch your head wondering why your layout is broken.
8. Inline styles are hard to read and edit: Most CSS authors write external stylesheets with one rule per line; when placed inside HTML elements, they're part of a jumble of markup, content, scripts and styles. It's not hard to see the enhanced readability of the second example below:

   <p style="color: #fc0; font-weight: bold; display: none; position: relative; left: -50px; top: 200px; float: left;">Lorem ipsum dolor sit amet, consectetur adipiscing elit. <a href="http://www.google.com" style="text-decoration: underline; display: block; padding: 20px; background-color: #930; color: #fff;">Quisque nisl</a>. Quisque velit leo, <span style="font-style: italic; color: #ffc;">ultricies nec</span>, lobortis quis, iaculis ac, est.</p>

   p {
   	color: #fc0;
   	font-weight: bold;
   	display: none;
   	position: relative;
   	left: -50px; top: 200px;
   	float: left;
   }
   a {
   	text-decoration: underline;
   	display: block;
   	padding: 20px;
   	background-color: #930;
   	color: #fff;
   }
   span {
   	font-style: italic;
   	color: #ffc;
   }

9. Inline styles encourage poorly structured markup and CSS: When you're moving your inline styles to a stylesheet, you're likely to replace every style attribute with a class or id attribute so you can apply your rules to the correct elements. This apparent time-saver will keep you from unlocking the real power and elegance of CSS: the cascade. You'll think of every element on the page as a one-off, to be styled individually. You won't think about how to organize your selectors to apply common rules to base HTML elements while saving special styling rules for classes and ids. The result will be verbose, poorly factored CSS that's difficult to maintain.
10. Inline styles won't get much sympathy or help from your friendly neighborhood CSS expert: CSS experts employ a variety of tricks to minimize the pain of debugging. Religious devotion to external stylesheets is often the first line of defense. When you turn to your UI gal for help on a vexsome visual issue, she may well tell you to move all of the CSS to external stylesheets before she'll even look at it.

So if inline styles cause cancer and destroy lives, why are they part of the spec in the first place? As with any tool in our technological arsenal, inline styles do have a purpose. They're best used to help you override your stylesheets in truly exceptional circumstances.

One example: Page elements to which visual effects will be applied with JavaScript. Many JavaScript animation frameworks perform even basic hide/show operations by manipulating the properties of individual DOM elements rather than classes. For your markup and styles to play nicely with such frameworks, you may well need to declare a small subset of style rules inline.

CSS experts: Are there any arguments against inline styles that I've missed? Are there any exceptions that I overlooked?

Developers: Have I converted you to the cause, or have you got convincing arguments to the contrary? And what other client-side questions can I answer in future installments?

Related posts:

1. Developer’s Notebook: Find computed styles in IE, Firefox, Opera or Safari
2. Ask a UI Guy: How should I structure my stylesheets?
3. What does your CSS Swiss Army knife look like?
4. Scriptaculous: Fixing Hover After Highlight
5. Design Pattern 4 – Inline help

Comments (0)

Software Development

Comments

• Leave a comment
• Comment feed for this post
• TrackBack URL

None so far.

Leave a comment