What's so bad about in-line CSS?

Question

When I see website starter code and examples, the CSS is always in a separate file, named something like "main.css", "default.css", or "Site.css". However, when I'm coding up a page, I'm often tempted to throw the CSS in-line with a DOM element, such as by setting "float: right" on an image. I get the feeling that this is "bad coding", since it's so rarely done in examples.

I understand that if the style will be applied to multiple objects, it's wise to follow "Don't Repeat Yourself" (DRY) and assign it to a CSS class to be referenced by each element. However, if I won't be repeating the CSS on another element, why not in-line the CSS as I write the HTML?

The question: Is using in-line CSS considered bad, even if it will only be used on that element? If so, why?

Example (is this bad?):

<img src="myimage.gif" style="float:right" />

Answer 1

Inline CSS will always, always win in precedence over any linked-stylesheet CSS. This can cause enormous headache for you if and when you go and write a proper cascading stylesheet, and your properties aren't applying correctly.

It also hurts your application semantically: CSS is about separating presentation from markup. When you tangle the two together, things get much more difficult to understand and maintain. It's a similar principle as separating database code from your controller code on the server side of things.

Finally, imagine that you have 20 of those image tags. What happens when you decide that they should be floated left?

Answer 2

Even though I totally agree with all the answers given above that writing CSS in a separate file is always better from code reusability, maintainability, better separation of concerns there are many scenarios where people prefer inline CSS in their production code -

The external CSS file causes one extra HTTP call to browser and thus additional latency. Instead if the CSS is inserted inline then browser can start parsing it right away. Especially over SSL HTTP calls are more costly and adds up additional latency to the page. There are many tools available that helps to generate static HTML pages (or page snippet) by inserting external CSS files as inline code. These tools are used at the Build and Release phase where the production binary is generated. This way we get all the advantages of external CSS and also the page becomes faster.

Answer 3

Even if you only use the style once as in this example you've still mixed CONTENT and DESIGN. Lookup "Separation of concerns".

Answer 4

Using inline styles violates the Separation of Concerns principle, as you are effectively mixing markup and style in the same source file. It also, in most cases, violates the DRY (Don't Repeat Yourself) principle since they are only applicable to a single element, whereas a class can be applied to several of them (and even be extended through the magic of CSS rules!).

Furthermore, judicious use of classes is beneficial if your site contains scripting. For example, several popular JavaScript libs such as JQuery depend heavily on classes as selectors.

Finally, using classes adds additional clarity to your DOM, since you effectively have descriptors telling you what kind of element a given node in it is. For example:

<div class="header-row">It's a row!</div>

Is a lot more expressive than:

<div style="height: 80px; width: 100%;">It's...something?</div>

Answer 5

Having to change 100 lines of code when you want to make the site look different. That may not apply in your example, but if you're using inline css for things like

<div style ="font-size:larger; text-align:center; font-weight:bold">

on each page to denote a page header, it would be a lot easier to maintain as

<div class="pageheader">  

if the pageheader is defined in a single stylesheet so that if you want to change how a page header looks across the entire site, you change the css in one place.

However, I'll be a heretic and say that in your example, I see no problem. You're targeting the behavior of a single image, which probably has to look right on a single page, so putting the actual css in a stylesheet would probably be overkill.

Answer 6

The html5 approach to fast css prototyping

or: <style> tags are no longer just for the head any more!

Hacking CSS

Let's say you're debugging, and want to modify your page-css, make a certain section only look better. Instead of creating your styles inline the quick and dirty and un-maintainable way, you can do what I do these days and take a staged approach.

No inline style attribute

Never create your css inline, by which I mean: <element style='color:red'> or even <img style='float:right'> It's very convenient, but doesn't reflect actual selector specificity in a real css file later, and if you keep it, you'll regret the maintenance load later.

Prototype with <style> instead

Where you would have used inline css, instead use in-page <style> elements. Try that out! It works fine in all browsers, so is great for testing, yet allows you to gracefully move such css out to your global css files whenever you want/need to! ( *just be aware that the selectors will only have page-level specificity, instead of site-level specificity, so be wary of being too general) Just as clean as in your css files:

<style>
.avatar-image{
    float:right
}
.faq .warning{
    color:crimson;
}
p{
    border-left:thin medium blue;
    // this general of a selector would be very bad, though.
    // so be aware of what'll happen to general selectors if they go
    // global
}
</style>

Refactoring other people's inline css

Sometimes you're not even the problem, and you're dealing with someone else's inline css, and you have to refactor it. This is another great use for the <style> in page, so that you can directly strip the inline css and immediate place it right on the page in classes or ids or selectors while you're refactoring. If you are careful enough with your selectors as you go, you can then move the final result to the global css file at the end with just a copy & paste.

It's a little hard to transfer every bit of css immediately to the global css file, but with in-page <style> elements, we now have alternatives.