Inline CSS style attributes get a bad press - but sometimes they can be A Good Thing.

If you have read anything about CSS in the last five years, you will know that inline CSS styles are A Bad Thing. Some claim that the existence of inline styles demonstrates bad programming. CSS should be in included static files, which can be combined, compressed, and cached. Better for performance, re-use, maintainability and developer happiness, which is a win-win-win-win situation.

The problem with this is that it often ends up with a bewildering array of micro-styles, catering for every possible situation, which can in turn make maintenance harder, and not easier. There is a reason why CSS pre-processors suddenly appeared on the scene - maintaining large a CSS codebase is just too damned hard.

Before telling you why I think inline styles are sometimes a good thing, I'm going to do a sidestep into what CSS does for us in the first place. This is a very simplistic, and opinionated, overview - if you want to know what CSS really does I would recommend heading over to @necolas' blog (as a side note, he used to work for me - how times have changed!)

CSS, IMO, is good for two things - structure and style. By structure I really mean the underlying page grid and how components flow within it. This includes all the structural components - positioning, floating, etc. This is the invisible skeleton of your site. Style is the visible decoration: font choice (family, style, size, ...) colours, the box model (padding, margin), backgrounds etc. All of these elements make up what could be called the 'style guide' - the canonical reference to the way that the site should appear when 'dressed' with CSS. With these two it should be possible for a developer to build a new web page that looks and feels like the rest of the site. (Strange how it never really works out like that.)

There is a third component to this, which is the use of CSS selectors as hooks for JavaScript DOM related-functions - I'm not a fan of this at all, and strongly subscribe to the 'semantic' CSS philosophy in this regard - if a class is used for hooking up JS, then give it a 'js-' prefix so that it's clear what its use is. Don't reuse styling classes - it makes the CSS very brittle - it's like making an HTML Prince Rupert's drop.

So, this is the thing. In order to have really clean, clear, semantic and re-usable CSS, you need to avoid the edge cases. Because the fact is, even though the rest of your site is font size 16, blue, left-justified, there will always be one thing that needs to be exactly the same... but different. 'Best practice' would have you create a new style for this, or possibly refactor your existing CSS so that styles can be combined to create the desired affect. Personally I think that if you have a style that consists of a single attribute, and that appears on a single page (/view/template/whatever), then just make life easier for yourself and put it inline; you can thank me later.

(PS if your inline style starts popping up in different places then you can always refactor it at a later date. It's really not that hard.)