Summa

The following blog post is written for any developer who has experienced working on a web based application, and during such project, altered the front end code (css, html, jsp, xhtml, aspx, php, etc.)…

After consulting as a UI developer on a range of web applications, I’ve run into many different coding behaviors/standards. These projects range from annoyingly brittle to flexible and well designed. Yet, in every single one of these web projects, I found a troubling coding “pattern” that would eventually lead to maintenance headaches. What is this horrible “pattern” you ask? It is… (drum roll) the prevalent usage of inline styling (CSS)… ugh.

I can already imagine some developers scoffing (laughing?) at the idea that inline styling could be “troubling”. Well, let me stop and boldly say… it is bad practice that will ultimately hurt a project in the long run.

Reasoning behind NOT using inline styles

For clarity, one may even ask: What is inline styling? Let me give you this one code example:

<span style=”not:needed; bad:practice; foo:bar;”></span>

Let me ask all you developers/consultants out there a few questions…

Have you ever handed off code to a client that contained inline styling (style=”foo:bar;”)? Was there an expectation for the client to take over on the maintenance of this application? Have you ever worked on a web application that supported print? If so, did you try printing a page from your app through all of your supported browsers? Speaking of browsers, ever work on an application that had to support an ever growing number of browsers IE6+, Firefox, Opera, Chrome, Safari… etc, etc.?

All of you may have varying answers, but I guarantee the answer to the first question is always “YES”.

Initially, I see why a developer would use inline styling during their development phase… it’s easy and you can quickly to see results on the screen. Check that in, and you’re done… STOP!

Why? Think about this, take that style=”margin-left:10px;” code and multiply it by, let’s say, 5 DIV tags, on the page you are implementing. Ok, now let’s multiply that page by, let’s say, 50 pages in your application. Now, let’s say, one of those DIVs needs a change to be made, based on new requirements. You have officially made 250 indistinguishable style references, finding one to fix or update would be quite annoying. Also the margin for error seems to be high. Factor the number of developers into the equation, and you could have a recipe for duplication in the code that becomes unmanageable.

Before, you check in that style=”margin-left:10px;”, I say make the extra effort to pull out all your inline styles for that particular DIV, and put them on your style sheet as a new or altered style class. If you uniquely name your classes and parent classes, changing that one DIV among many, may be as simple as this:

Code that needs to change, without affecting other EXACTLY NAMED child DIVs:

HTML
<div id="uniquelyNamedParentDiv" class="uniquelyNamedParentDivClassName">
<div id="childDiv" class="divClassName">
</div>
</div>

CSS
.divClassName { margin-left: 10px; }

New code changed for specific child DIV (”Look ma, no HTML changes necessary!”):

CSS
.divClassName { margin-left: 10px; }
/* .the following was added for a div that needed to move 90px more to the left. */
.uniquelyNamedParentDivClassName .divClassName { margin-left: 100px; }

…And if you truly uniquely named that parent DIV, you can easily search your code to find the div you need to change. What if you had two child DIVs with the same class name within that uniquelyNamedParentDivClassName DIV, but you only wanted to change one? Well, now you have the chance to use a second, newly created style for that child DIV…

Example:

HTML
<div id="uniquelyNamedParentDiv" class="uniquelyNamedParentDivClassName">
<div id="childDiv1" class="divClassName">
</div>
<div id="childDiv1" class="divClassName newlyAddedDivClass“>
</div>
</div>

CSS
.divClassName { margin-left: 10px; font-weight:bold; }
/* .the following was added for a div that needed to move 90px more to the left. */
.newlyAddedDivClass { margin-left: 100px; }

What about inline styles for dynamic behavior?

Now, what about those styles that you need to change dynamically? For example, what if you need to use style=”display:none;” to hide a DIV during one situation, but for another situation, you need to show the DIV using style=”display:block;”. Well, let’s stop by saying that there is never a case that truly needs inline styling. The following example shows how to use multiple style classes for the same effect*:

Questionable code:

HTML
<div id="dynamicallyVisibleDiv" style="display: none;" class="dynamicallyVisibleDivClass">
...blah blah, you can't see me...
</div>

Suggested code:

HTML
<div id="dynamicallyVisibleDiv" class="dynamicallyVisibleDivClass display-none">
...blah blah, you still can't see me...
</div>

CSS
.display-none { display: none; }
.display-block { display: block; }

*If you smartly implemented a fully developed javascript library like jQuery or dojo, you can easily manipulate the tag elements to replace classes like .display-none with .display-block, or just remove .display-none without replacing it.

Using classes to help with print

Have you ever used style=”overflow:hidden;” on a div because it made certain scrollbar oddities disappear? This is all well and good… unless you have to print the page. Although overflow is a really helpful style attribute, it does cause some print issues in certain browsers, noticeably found in Firefox. With that in mind, I suggest using a class, rather than inline styling, to set the overflow behavior, so that when in print mode, it can easily be reverted…

Questionable code:

HTML
<div id="printDiv" style="overflow: hidden;" class="printDivClass">
...blah blah, I do not have un-needed scrollbars, but if you print this page in Firefox, I will only show up as one page...
</div>

Suggested code:

HTML
<div id="printDiv" class="printDivClass overflow-hidden">
...blah blah, I do not have un-needed scrollbars, but if you print this page in Firefox, I will only show up as one page, BUT, now you can easily revert this in a print.css file...
</div>

CSS-Normal
.overflow-hidden { overflow: hidden; }

CSS-For-Print
/*reverting all overflow:hidden cases to visible, in order to prevent missing pages on the print out.*/
.overflow-hidden { overflow: visible; }

Going forward

To sum this all up simply: I suggest that if a team implements a rule of “no inline styling!” from the start of all development, ultimately as the project proceeds, there will be less confusion about the process/implementation among the developers, and there will be a level of ease when refactoring styling, if needed, during the QA phase of a project.