Inline Styles for the Fail

Jeremy Hilts, Web Developer

I’ve said it before and I’ll say it again: inline styles are bad. Mmkay?

Hey, I know what you’re thinking … if you’re allowed to do it, how can it be bad? Just because you won’t go to jail for cutting your toe off doesn’t mean you should be cutting your toes off. Do you remember our conversation about IDs being too specific? Same thing. Except worse. Much worse.

In any situation where an ID has been used and needs to be overridden, you could always use more IDs or a later definition of the same selector. Basically, “#big_section #small_section” is more specific than “#small_selection”; but if you don’t have “#big_section” you could always define “#small section” in a second CSS file or later in the same CSS file. Granted, I can’t think of any good reason to have the same selector twice in the same file, but it’s still possible. A later definition, top-to-bottom, of an equivalent selector is always more specific.

So now you may be wondering: why do inline styles have such a bad rap? For one, you’re breaking the separation between style and structure. For two, they can’t be overridden. From least- to most-specific, it goes: class, element, element.class, element.class.class (and so on), ID, and in-line style. There is nothing more specific than an inline style.

More often than not, I find inline styles used as “band-aids.” It’s a quick fix to a bug or “I couldn’t figure out a better way.” But as with all structural band-aids, they’re good in the short term and bad in the long. The basic principle behind the ideological separation of church and state — I mean, style and structure — is that you can change one of them, entirely, without affecting the other. For a site redesign, you’d need only change the CSS and would be able to leave your markup (or whatever is generating your markup) alone. In the case where there are a bunch of inline styles, you now have to remove every single instance of them or mitigate them separately.

I’d made a joke in my first blog post that I took the MacGyver approach to coding — I meant this very loosely. While MacGyver could come up with a solution to any problem, he never meant for his death ray made of chewing gum, coat hangers and paperclips to last longer than it took to get rid of the bad guys. I’d like to think that if MacGyver were engineering something that was meant to last, that he’d spend some time using the proper materials and practices.

Realistically, the only situation that I can think of that you would, absolutely, need to use inline styles is if you were writing a blog post and wanted to do something really fancy; but even then, most blogs remove the ability to add markup to your posts.

So the moral of the story is: unless a group of bad guys tell you that they’re going to blow up a children’s hospital if you don’t write them a super-fancy post on their markup-enabled blog, don’t use inline styles. Inline styles are bad.

Share and Enjoy

•