Collision Proofing Your CSS

There will be at least some occasions where you have a standard piece of HTML that you add into your web pages whenever you want to include a particular piece of content into the page. There will of course be no problem with the HTML conflicting with anything else on the page unless that HTML contains one or more ids that are also used for other purposes in your web pages. The simplest way of ensuring that the HTML does not "collide" with the other HTML in your web pages is to come up with a standard naming convention to use for your ids for use in your common HTML fragments so as to ensure that such duplication of ids does not occur.

What you will most likely have associated with the HTML in order for the content to not only appear in the page but also so that it looks and behaves appropriately is some stylesheet commands and possibly JavaScript that is intended to specifically apply to and interact with that HTML. Unlike the HTML where it is only ids that can collide with the other parts of the page, there is a far greater possibility of the JavaScript interfering with other JavaScript on the page and a greater possibility even than that of the stylesheet commands interfering with other content on the page.

As the styles are the thing most likely to have issues when you combine a fragment of HTML into a web page, let's consider how we can defensively code our CSS so as to minimize the possibility of such collisions occuring. There are two ways that this can happen.

  1. The styles intended for the HTML fragment get applied to other parts of the page
  2. The styles from the main part of the page get applied to the fragment.

There is a simple way to remove all possibility of the first of these occuring and also a way to minimize the possibility of the second occuring. Let's go step by step through the process of coding the CSS for our HTML fragment in such a way as to collission proof the CSS.

The first thing we will want to do is to make sure that the HTML fragment has a div (or some other appropriate element) wrapped around the entire content of the fragment and that wrapper element has an appropriate id which uniquely identifies what the HTML fragment is for using our standard naming convention that ensures that the same id is not used anywhere for anything else. In most curcumstances there should be no need for any other ids anywhere within the fragment.

The next step is to write the CSS that you need in order to style the HTML the way that you want it to look. The best way to do this is to stick the fragment into a dummy wrapper page that has no other content but which does have the appropriate doctype and the other tags that you expect to have within any page that you plug your fragment into.

What you now have is a fragment of HTML and associated CSS that can be plugged into a web page and will display correctly provided that there are no conflicts between the CSS for the fragment and the CSS for the rest of the page. The next step is to remove the possibility of the CSS for the fragment being applied to any part of the page outside of the fragment that it is intended for.

To best explain the next step in the process, let's look at an example. Here's the CSS for part of my Piano Chord Calculator as I originally wrote it.

.l {border-left:1px solid #ccc;border-right:1px solid #fff;}
.lr1 {float:left; width:1px;height:60px;border-left:1px solid #ccc;}
.lr2 {float:left; width:1px;height:30px;border-left:1px solid #ccc;}
.wt {float:left; height:60px; background-color:#fff;border-top:1px solid #ccc}
.wb {float:left; height:30px; background-color:#fff;border-bottom:1px solid #ccc; border-left:1px solid #ccc;border-right:1px solid #fff;}
.bl {float:left;width:11px; height:60px; background-color:#000;border:1px solid #ccc}

What we need to do is to amend this code to make sure that it doesn't get applied to anywhere else in the page that might just happen to be using the same class names for some other purpose. We do that by prefixing all of the references with the id of the wrapper so that the styles will only be applied within the fragment. So if our fragment has a wrapper id of "kbd" we would change the above CSS to the following.

#kbd .l {border-left:1px solid #ccc;border-right:1px solid #fff;}
#kbd .lr1 {float:left; width:1px;height:60px;border-left:1px solid #ccc;}
#kbd .lr2 {float:left; width:1px;height:30px;border-left:1px solid #ccc;}
#kbd .wt {float:left; height:60px; background-color:#fff;border-top:1px solid #ccc}
#kbd .wb {float:left; height:30px; background-color:#fff;border-bottom:1px solid #ccc; border-left:1px solid #ccc;border-right:1px solid #fff;}
#kbd .bl {float:left;width:11px; height:60px; background-color:#000;border:1px solid #ccc}

This change ensures thhat the CSS intended to apply to the HTML fragment does not get applied to anywhere else in the web page.

Handling the reverse situation is not quite as straightforward. To ensure that the CSS intended for the rest of the page does not interfere with the appearance of thhe HTML from our fragment we need to make sure that a more specific style definition for the fragment exists for every situation. Adding the id as we have already done goes part way toward resolving this aspect of stylesheet collissions as it ensures that the styles to apply to the fragment are more specific than they would otherwise have been since they are now being told to only apply to the fragment. This ensures that where there are styles with the same class name to apply both within and outside the fragment that the appropraite one is applied in the right place.

The only situation that we have left to worry about regarding collissions in the CSS is where styles defined for the rest of the page get applied to our fragment due to our not having specified a value for those properties in the CSS for the fragment. Generally this would mean that we would be picking up a browser default for thoose properties in any case and therefore the value that we would have even with nothing else on the page could vary depending on which browser we are using. This either meanns that the value iis unimportant and we can just let the browser or more general CSS for the page decide what those values should be or if it is important then we should have specified the value in the CSS to start with in which case the changes that we have already applied to the CSS will resolve the issue. Of course you may not have noticed that there is a situation like this until such time as you add the fragment to a page that changes a property to a totally different value than you are picking up everywhere else you are using the code. That would then be the time to go back and add the appropriate extra property definitions into the CSS for your HTML fragment in order to resolve that issue and reduce the possibility of further collissions in the future.

 

This article written by Stephen Chapman, Felgall Pty Ltd.

go to top

FaceBook Follow
Twitter Follow
Donate