2011.07.24

Pragmatic CSS: using JS and inline styles

I’ve been working on many different kinds of projects through the past years, some of them with a very short lifespan (3-6 months) and almost no maintenance after launch and others with constant updates and planned to last for many years, from facebook applications to mobile websites, microsites, intranets and large dotcoms… I committed a lot of mistakes and done a few things right as well. One thing that I’ve been realizing is that some things that are usually considered “bad practices” sometimes can be the most productive solutions and that the drawbacks from taking a “shortcut” may not exist if you do it with caution.

I’m a huge advocate of clean and maintainable code, I really believe that grouping things by context is usually the best approach – style should be stored on external stylesheets, JavaScript should be on external files as well and the HTML should only hold the markup and content… - But I also think that best practices exists for a reason and we can’t forget what kind of problems they solve and why they were created, following rules blindly is almost as bad as breaking them without a good reason.

I’m going to try to explain some cases where inline styles and using JavaScript to set styles can be the recommended approach. – To all the zealots out there, try to understand that each project have different goals and requirements and that what is often considered a bad practice can be a reasonable solution in some cases…

When to use inline styles

CSS was created to separate content from style, that way developers could switch the style without changing the markup, reduce a lot the code duplication (smaller files and easier to author/edit) and increase organization. - specially because of stylesheets being shared across multiple pages and also because of cascading/inheritance - But sometimes we need to apply styles to a single element that we are sure won’t repeat anywhere else on the site (at least not yet), or we are coding something really simple like a small single page website, the default approach in those cases is to probably create a new CSS class or an unique ID for each element that needs a different rule. I’ve seen a lot of people doing something like this (including myself):

  <style>
    p{font-size:14px; margin:1em 0; color:#555}
    #callout-unique{margin-top:50px; font-size:2em}
    .awesum{color:#BADA55}
  </style>
  <p>This is a regular paragraph.</p>
  <p id="callout-unique">This is an unique paragraph that only happens once on the whole site.</p>
  <p class="awesum">This color is only used once on the whole site.</p>

Which is almost identical to:

  <style>
    p{font-size:14px; margin:1em 0; color:#555}
  </style>
  <p>This is a regular paragraph.</p>
  <p style="margin-top:50px; font-size:2em">This is an unique paragraph that only happens once on the whole site.</p>
  <p style="color:#BADA55">This color is only used once on the whole site.</p>

Yes, almost identical… The difference is that when you use an ID/class you are grouping all the styles into the same location (which can be good for organization), but you are still applying the rule to a single element, it needs a few extra bytes, it takes a little bit longer to come-up with an ID/class name and you have to write it twice (once on the markup and once on the stylesheet)

Let’s say you have a page with 10, 20, 50+ unique elements that have some specific rule that you are sure won’t repeat (maybe just a different margin/padding, slightly different font-style, background-image…), do you still believe that the best option is to create unique IDs for each one? Do you really believe that updating the ID in 2 different places (in case you decide to rename it or delete the element) is the best thing for maintainability? Are you sure it will be easier to find it inside a 1000+ lines CSS file or through 15 different stylesheets than to simply update the markup?

Inline styles can speed-up the initial development time (specially for prototypes and simple applications) and can also help you to increase code reuse on larger sites when done right - if you create a class name that is overly specific (e.g. .mainNav, .faqItems, .contactForm) it is very uncommon to reuse the same class names on other elements, even if they have a lot of properties in common, since the name won’t have the proper semantic meaning - waiting until you spot the shared properties can help you name classes better and create pieces of reusable code. It’s very uncommon to make drastic design changes without updating the markup - CSS zen garden is a nice concept but not that common on real-life - so having a few styles on the markup may even improve maintainability in some cases.

Refactoring

I’m not saying you should always favor inline-styles, I’m just saying that if you need too many IDs or unique styles it may be a good idea to keep it as an inline-style until you need to apply it on another element and/or page, as soon as you need it somewhere else you should extract it and create a new class that contain the common rules and remove the inline style. You will benefit from not having to switch from the HTML file to the CSS file during the initial development (saving time) or creating IDs/class names that are overly specific (increasing the chance of code reuse) and than later you abstract only the rules that will really benefit from a separate stylesheet.

“Nobody” writes clean code from the “first shot”, refactoring is an important part on every software life, make it work first than improve the structure at each iteration (always making sure you aren’t breaking anything).

Don’t forget about caching and multiple pages

It’s also good to remember that stylesheets are cached across pages and reloads, so if you have unique elements like headers, footers or menus, having an unique ID/class is still the recommended approach since the user will load the styles only once and you don’t need to update each individual HTML file in case of changes. Inline styles should be only used for elements that are completely unique and won’t repeat between pages and to set properties that aren’t shared between many elements. - e.g. On a recent project I had to position many elements based on the center of the parent element, so I created a class .absmid{position:absolute; top:50%; left:50%} and than I set the margin-top and margin-left of each element using inline-style, that way I was benefiting from the shared properties and only declaring unique ones.

When to set styles using JavaScript

I’ve seen a lot of people saying that we should avoid updating style properties using JavaScript, that we should favor adding/removing classes since it will make maintenance easier and it is better for performance. That is usually truth but not always… If a certain style rule is required for the JavaScript function/component work properly the property should be set using JavaScript.

Let’s say you are coding a scrollbar and it requires that the parent element of the content must have overflow:hidden and position:relative, if those rules are set using CSS an unwarned designer/developer may remove or change those rules without noticing that they broke the component or the JS developer may not know if the rule was already set or not (that for me is a maintenance nightmare). It doesn’t mean you should keep all the style inside the JS file tho, properties used for skinning the component (colors, font, etc..) should be stored on a stylesheet, that way design can be easily updated without changing the structure (JS). If the style changes the behavior of the script than it isn’t just a “styling” property, it is an structural/behavioral property and should be grouped together with the “layer” that adds behavior (JavaScript).

JavaScript should be also used when styles need to be set according to some dynamic value (e.g. calculate size/position dynamically) or when you need to update a value through time (e.g animation). You should favor adding/removing classes only when it makes sense.

Conclusion

Understand why something is considered a “best/bad practice” and analyze if it does apply to your specific scenario, maybe you are taking the “long path” without any real benefit…

Be pragmatic.

PS: Not so long ago I had a complete different point-of-view about this subject and I still create overly specific class names and regret about choosing the “wrong” approach sometimes… This post is also a reminder to myself.

Further reading


Comments

[...] Pragmatic CSS: using JS and inline styles Tags: best practices, css, design patterns, random thoughts Comments (0) [...]

I just got scolded for using CSS in my web app when the lead dev told me I should be using javascript to set my css. I honestly couldn't understand why it was issue (as long as the app worked) but this reverberated his thinking as well as mines (Behaviors vs Skinning) We're using a custom version of backbone so things can get rather wonky. I'm definitely going to keep using CSS to skin and pure javascript for behaviors and events. My sanity thanks you.

Good day! Do you know if they make any plugins to help with SEO? I'm trying to get my blog to rank for some targeted keywords but I'm not seeing very good results. If you know of any please share. Thanks!

Here is my blog [watch movies online app ipad](http://1channel.ph "watch movies online app ipad")

We absolutely love your blog and find a lot of your post's to be exactly what I'm looking for. can you offer guest writers to write content for yourself? I wouldn't mind creating a post or elaborating on a number of the subjects you write related to here. Again, awesome web site!

Look at my webpage; [camera devices](https://independent.academia.edu/HenriettaStrunk/Posts/2944456/W-uld-b-C-non-EOS-l-ns-buyers-have-choice-f-genuinely-excellent-l-n-es-to-select-fr-m.-Thi-Can-n-Ma- "camera devices")

Leave a Comment

Please post only comments that will add value to the content of this page. Please read the about page to understand the objective of this blog and the way I think about it. Thanks.

Comments are parsed as Markdown and you can use basic HTML tags (a, blockquote, cite, code, del, em, strong) but some code may be striped if not escaped (specially PHP and HTML tags that aren't on the list). Line and paragraph breaks automatic. Code blocks should be indented with 4 spaces.