Coding with Jesse

When to use inline JavaScript and CSS

December 10th, 2006

Unobtrusive Ajax is about keeping all JavaScript and CSS out of the HTML. This is a good idea. You certainly shouldn't be using onclick or onmouseover attributes in your HTML, and you should really avoid using the style attribute. But what about putting JavaScript inside a <script> element or CSS in a <style> element directly in the HTML?

Most people would recommend that you never do this, that you keep every line of your JavaScript and CSS in an external file. I'd say, never say never. There are certainly occasions I do this, although rare, but I think these scenarios make sense. So let me outline some of these scenarios where you may want to use inline JavaScript and CSS:

  • The JavaScript or CSS is specific to one page

    You may be doing something really specific, such as some animations or ajax in a web application interface, where this code won't be reused on any other pages on your site. In this case, you won't gain any benefits of reuse in an external file.

  • The page won't be accessed very often

    If the page is an obscure page in your web application that users only access once, or only once every few months, then you won't gain the benefits of having the browser cache these external files. You'll actually slow things down by making the browser make two extra requests for the JavaScript and CSS.

  • You just want to use a few lines of JavaScript or CSS

    This is a common scenario with a lot of JavaScript libraries. The instructions often involve including an external file, then putting maybe 1-3 line of JavaScript on the page that initializes some widget. It would be totally wasteful to create an external file containing only 1-3 lines of code. The time wasted downloading an extra file would counteract any benefit gained from caching the file later.

These scenarios don't happen so often. As long as you don't care about the browser caching the CSS and JavaScript separately, and you don't need to reuse the CSS and JavaScript throughout your site, or it's just a few lines of code that isn't worth caching, I see nothing inherently wrong with using inline JavaScript and CSS. Your visitors won't notice or care. It's even valid still, as long as you keep the <style> in the <head> and wrap your JavaScript in a CDATA (for XHTML). So if it makes things a bit easier for you, I say go for it.


1 . trovster on December 11st, 2006


BTW, that's called 'internal' CSS/JavaScript. External (obvious) Internal is in the head, and Inline is within the elements themselves. I use the same technique for dynamic CSS on certain pages.

2 . lewis on December 12nd, 2006


hi jesse,

been following your blog for a few weeks now - very down to earth and genuine.

'You certainly shouldn't be using onclick or onmouseover attributes in your HTML'

why is this? or have i missed something?


3 . Jesse Skinner on December 12nd, 2006

Jesse Skinner

That's a great question, Lewis. It's great because I can't really answer it. I suppose for all the reasons that I said inline (internal) JavaScript and CSS is sometimes okay, I guess even onclick and onmouseover is sometimes okay.

These event attributes can be problematic if they cause the page to require JavaScript (ie. <a href="#" onclick="doSomething()">), or if you want to keep your JavaScript grouped together in a reusable, cacheable external file. It's also better (and easier) to use CSS for mouseover effects when possible.

Having nice clean HTML is something to be proud of, but really, nobody is going to look at your HTML source except you, so just do whatever's easiest as long as you're not hurting your visitors.

4 . lewis on December 12nd, 2006


nice one,

yea, i have used js with the hash like that before in the past. if i remember rightly ie6 used to refresh the main page whenever you opened the pop up - quite unnerving, especially if you were in the middle of a form.

i'm glad you mentioned css though. i built a site recently using 'pue css' (if i'm correct in how i regard that phase) which included everything from images to rollover nav hyperlinks. a good friend of mine pointed out - 'what if you disable css? how do you navigate?'. strange thing was, i got the idea from ISBN: 0735712018! my tutor marked me high on it, but looking back, it wasn't very accessible. i suppose you have to ask yourself who doesn't have css enabled. regardless, certainly a safer bet that asking the same question about js.

unless, visually, the site is really special, or the content particularly engaging, i tend to disregard any site that doesn't use a strict dom now - it might sound a horrible thing to say, but i find looking through people's code quite fascinating. it's a learning curve in many cases i think.

thanks for the help jesse,

5 . demods on January 13rd, 2007


You should also consider about dynamicaly generated script codes. Some pages really need some dynamic javascript codes, like rendering different javascript menu items on different pages. I think that's the biggest need to use inline/internal (or what ever you call) scripting.

Most of the webpages are built on some server-side language, like PHP, ASP etc, and building a dynamic menu requires dynamic javascript codes. Instead of generating the codes, writing them in an external js file, saving that external file, and including it on the page (which is not very practical), with only 10-15 lines of javascript code, you can build your page specific javascript menu.


6 . Ant on February 4th, 2010


Don’t agree, because it makes editing html harder. And it makes pages bigger a bit.

It’s easier to edit all js in one file, even if it only happens once.

7 . Ant on February 4th, 2010


And about inline css: it’s harder to debug with Firebug than css via classes.

Comments are closed, but I'd still love to hear your thoughts.