If you haven’t read part one, this is a highly edited version of an internal document, on the topic of creating a company standard for html, css and javascript work, with some of the (justified) language toned down.

Part 1 of the post may be found here.

Rule 4: Use Sprites

Sprites are a method of bundling the graphics on your site together, so that user’s browsers don’t open as many connections to your server. They can improve the loading time of a website, particularly one with many small graphics, and can especially improve situations where only parts of a website load initially, resulting in a “flash of un-styled content”. They’re not perfect solutions for everything (examples below), but done right they’re helpful.

• A useful FireFox tool for creating sprites is SpriteMe. See: http://spriteme.org/
• Image buttons should use sprites if they have rollover effects, and if spriting is feasible. One example would be where you need your buttons to be scalable, and thus you use multiple images to form pieces of the button. Placing all of them in a single sprite will greatly improve your sites loading performance. It can be difficult to get this to work identically across different types of browsers though.
• It is ok to not follow SpriteMe’s suggestions completely. In particular, it is ok to have several sprite images (i.e. for buttons).
• It is ok for some images to not be inside a Sprite – particularly if you find it too difficult to position them properly as a result of spriting them. If you need the ability to position an element as well as aligning its background, or if you don’t have tight control over its size (i.e. due to user-contributed content), it may not be feasible to use sprites.

Rule 5: Clear and Concise CSS

There should not be an excessive number of css files. Bear in mind that many browsers – particularly older ones – can only load a certain number of css files. Also bear in mind that too many css files will make it extremely difficult to maintain your css later on. Many modern frameworks and CMSs have the ability to automatically compress your css files down to a singleton, which is often helpful.

One possibility for structuring your css (obviously if you’re using a framework, then use its own format):

• general.css (or some similar name) – please set standards for things like body tags, default fonts, headers etc etc here. Understand that if you set something here it will be used EVERYWHERE else on the website unless it is specifically overwritten, so don’t set a generic rule unless you want every tag of this sort to look at least roughly like this.
• reset.css – if you need a reset file, you’re probably doing something wrong elsewhere, but in emergencies this is acceptable.
• layout.css – set large scale positioning for your layout here. If you have more than one layout in the project, you may have separate css files – but please name them in a useful way.
• A small number of css files with specific overrides of the generic appearance; if there are too many, be prepared to defend your reasoning. Examples could include a file specifically targetting older versions of IE.

If you aren’t using a framework, I strongly suggest using minify (or something similar) to compress and combine your css.

Another Note: The deeper you nest a tag reference (i.e. div#main div#header div.dropdown ul li {…}), the more work a browser has to go through in order to render it. If you structure things properly and are not lazy about giving things classes and id’s, you shouldn’t need to go more than 3 deep (unless you need to target something specifically in a browser-specific css file). This may also have an effect with regards to SEO. (Note that Drupal’s form structure makes it impossible to follow this rule!).

*** Understand the difference between “id” and “class”” for css styles. An “id” means that you are setting the name of something. There can ONLY be one item in a page with a given id. If there are two items that share an id, you will break things. Don’t do it. A “class” means the general type of something – you can use that as often as you like on a page, but remember that it can’t be used to specify one item specifically. I’m always surprised by how often I encounter misused ids.

Rule 6: Maintainability

• Use proper indentation. If a tag is nested inside another tag, indent it. This allows your code to be easily read by another human.
• Use proper comments so that people in the future will know what you were trying to accomplish. That includes putting a brief closing comment at the end of a “div” tag for a major section of your page (really helpful if your editor doesn’t fold code properly, or if you’re trying to find a broken tag). Frequent comments in your css code are also extremely helpful later on.
• Do NOT use comments that contain rude words, or snarky stuff about particular browsers. Google WILL spider css and js files, in addition to your html. This will almost always cause you grief down the road. I have some amusing stories about people who did this. I might post them here.
• Don’t EVER use inline css in your HTML code. There are no exceptions to this rule. Give the tag a class or an id, and put the css in your code. It is difficult to maintain code that has inline css, and doing so shows gross inconsideration for the people who will be working on it in future (including yourself).

The third and final part of this post may be found here.