SiteKickr Web Development

Reasons to avoid inline CSS & JavaScript

Phil LaNasa

Every HTML page consists of three major components:

The skin/template should be separated from the content on the server-side, using a framework or layout method as described in my post on Site Structure. The presentation, however, needs to be separated on the client-side, using <style>, <link>, and <script> tags. This is one of the oldest and most-commonly-spoken-of  web development practices, and I'd like to go into detail on why this is such a good idea.

Essentially, what separation of content and presentation means is that we are to avoid embedding inline styles and scripts in our HTML content. For instance, this is a prime example of what not to do:

<a style="text-decoration: none;" onclick="alert('you clicked me!')">click</a>

Markup like this is found all over the web, often as a result of inexperienced web coders using graphical editors, but experienced web developers share the blame too. It's all too easy when 5 o'clock comes around and your taking every shortcut possible to get out the door, to forgo creating a style class, and instead just drop those styles right into the HTML tag.

Instead of just frowning on the practice, let's look at a few reasons why this separation is so important:

 

  1. Referencing bare HTML content is more difficult

    This reason doesn't present itself right away. It usually comes into play after a website has been launched, and it's content is consumed by services or clients other than a web browser. Because CSS and JavaScript is only useful to web browsers, anything else which references the content will either ignore it, or be negatively affected by it. You are, in essence forcing non-browsers to absorb presentational information when it carries no meaning.

    Search engines do a great job of ignoring the presentational items when they index your pages, but it doesn't mean they like it.
     

  2. Global presentational changes are difficult

    This one becomes apparent if you have more than 5 pages on your site, each with inline presentational elements. If you have a page title styled as such:

    <h1 style="font: normal 24rem/1.5rem Arial, Helvetica, sans-serif; color: green;">My page heading</h1>

    Then, at some point down the road, you decide that green isn't really the look you were going for with page titles, you need to manually adjust all of your HTML files, to make the inline style adjustment. This difficulty is compounded with JavaScript, as often times your editor's global file search/replace feature will be difficult to use against a multiline search.
     

  3. Future-proofing

    <script> tags currently validate inside elements (with XHTML you need to use the ugly //![CDATA[ trick), but there may be a time when they don't, as the <style> currently does not.
     

  4. Context

    During a presidential race, we hear phrases spoken by candidates, but out of context. The phrase may have carried meaning in the context of the content that surrounded the phrase, but alone, it carries no meaning or just makes them look bad. The same happens with CSS!

    To illustrate, let's say we have a block of content that we want to emphasize heavily by placing a 50 pixel black border around it, using inline CSS:

    <div style="border: 50px solid #000;">This content is so important that mobile users need to suffer!</div>

    This may present well on a 1024 pixel wide desktop browser, but on a mobile device, the border itself will take up nearly half the screen. To avoid this, we would typically have separate CSS files for mobile and desktop. But, there is no such separation when we use inline CSS.

    To illustrate in a different way, let's say we have the following inline CSS:

    <a style="color: #a00;">This is a red link</a>

    If this content is loaded on a device with a black & white screen, the red link styling is useless and only served to make the content itself take longer to download.
     

  5. Team environment 

    If you work in a team, it's likely that you have one team member dedicated to content (HTML), another to style (CSS), and still another to interactivity (JavaScript).

    If you are absent version control and a "check-in" procedure as so many small operations are, the logical course of action is to restrict access to HTML files to the person who edits the HTML, CSS files to the person who manages the CSS, etc. This serves to prevent one person from overwriting another's work if they are both accessing the same file at the same time.

    That system works well, unless you have CSS and JavaScript embedded in your HTML files. In this scenario, the person who manages CSS needs to say, "Hey Bob, can you close the file your working on for 20 minutes while I edit the inline CSS? When I'm done, don't forget to load the file from the server again so you don't overwrite my changes. Thanks Bob, you're the best, sorry for wasting 20 minutes of your day!"
     

  6. Markup to content ratio (bad for search engines)

    This one has been preached about by SEO wizards for years, so I apologize for duplicating it here. However, the list wouldn't be complete without it. Not only does inline style and script increase page load time, it increases the download time for search engines who are just looking for raw content. In effect, a search engine has downloaded additional information that it needs to discard anyway. This negatively affects how search engines position your site in two ways:
    • The content vs. markup ratio. It has been suggested the search engines frown when the amount of markup exceeds the amount of content by an undetermined amount (the ratio, of course, being dependent on the search engine). Without knowing the ideal ratio, it's a wise practice to keep markup to the absolute minimum required. This includes, of course, eliminating inline style and script when possible.
       
    • Page load. Recent evidence suggests that Google (and perhaps other SEs) factors your page load time into it's ranking algorithm. Essentially, with all other things being equal, a site with a faster page load will be ranked higher. As touched upon in the point above, inline style and script increase page load time.
       
  7. Performance

    We've touched on how inline style and script can negatively affect performance, but there's another side to that. Housing all of your CSS and JavaScript in external files can actually improve performance drastically. The magic comes from browser caching. A typical web site frequently updates content, but rarely touches style and interactive areas. With this in mind, most web hosting configurations are set to direct web browsers to cache CSS and JavaScript files.

    By caching these files in the browser, they do not require another HTTP connection to download them from the server. This post goes into more detail on browser caching.

 

With these seven reasons comes a compelling argument against the use of inline style and script, but by no means am I saying it is incorrect to do so. It is currently valid, and in very simple sites, may actually improve performance. In some cases, you can apply an inline style without coming in conflict with any of the reasons above. But, avoiding inline style and script usually leads to many years of happy and healthy web coding!