stevenclark.com.au

OK so you’re using CSS (Cascading Stylesheets) and a web standards methodology to develop websites. You’ve ditched table layouts, taken up the banner of best practice, and made a few changes in your staff or business culture to accomodate new ways of thinking. That’s all good stuff. But what about your overall CSS strategy? Do you still have contractors writing scrappy unmaintainable files? How do you pull all of it into a contigious software engineering strategy?

The first step is always the hardest - recognise the problem for what it is. And then implement systemic processes to address these deficiencies. This sounds simple because it is, but it will take a top-down implementation not just a corporate email. It’s the mind-shift from making websites that work (tentatively speaking) toward developing robust web based software as a profession. It’s sometimes only the polish that differentiates the former from the latter.

Step 1: CSS Delivery to the Outside World

My advice here is that most companies, if they even have a set template for inclusion of CSS files, do it on a case by case basis. Most aren’t even aware of the power that CSS gives them to deliver usable styles to older browsers and advanced layouts to more modern ones. Sit down with your team and figure out how to deliver your styles and ask them why that is the best way. I’d suggest something in your head section like:

1. Call a very basic stylesheet (basic.css) that Netscape 4 and older browsers understand - fonts, colour, size
2. Then use @import to call your main stylesheet (sitewide.css) for more advanced browsers using the screen media type
3. After the @import call your IE6 stylesheet (ie6.css) via Conditional Comments using the screen media type
4. Then call your print stylesheet (print.css) with the print media type

You might do all sorts of interesting things beyond that general setup. You just need to sit down, do some research and make a strategic objective about who will receive certain experiences on a website. It’s not good enough to just say it works on the latest and greatest - the site should degrade gracefully in older browsers.

Step 2: Split Up Your CSS Files

Take serious thought to how you’re going to split up your stylesheets. There is the trade-off of size versus the number of extra request / reponse cycles to the server. Don’t make them too small and keep them in logical order. Don’t go overboard. Do break them up intelligently. If a large number of styles only apply to your homepage perhaps there is a case for having a separate home.css file.

Step 3: One Author Owns the Stylesheets

Preferably a single author should be working on the stylesheets for consistency. This person should be identified and not have to scrabble over everyone else to constantly figure out what changes might be affecting the cascade or where someone has added extra padding.

Step 4: Write EITHER Concise Code or Redundant Code

At some point you’ve got a choice about whether you take full advantage of the cascade and write concise slick code that requires an expert to understand and debug (with smaller file sizes) OR whether to code for redundancy. You might have to provide these for an external entity to edit in future and a hodgepodge of both strategies can be more difficult to understand.

Step 5: Consider Indexing Your Stylesheets

Another maintainability strategy is to put an Index or Table of Contents at the top of each stylesheet. This shows the logical sections of the document and for a few extra lines there can be great comfort in not having to scour a whole document for a selector. Yes you can use Firebug or Firebug Lite to find a selector - but there is nothing like intimately knowing your code in the full context of the document. Firebug is my backstop, not my skillset.

Step 6: Vertical versus Horizontal

Do you author your stylesheets with the rules running down the page or do you let them maintain a horizontal perspective. My preference has moved from a vertical approach to a horizontal approach for several reasons:

• Horizontal allows me to see more selectors on the screen at a time
• They look less scrappy and seem easier to keep tightly organised
• And, I find them easier to maintain

Accompanying this is the question of the order you use to place rules for each selector. My preference is to use margin, padding and widths, then text and fonts, and move onto floats and bug fixes at the end. Whatever, you need to formalise this into writing so that everyone understands the order. This organisation within stylesheets turns them from scrappy into professional documents.

Step 7: Require Commenting

Not every part of a CSS file needs commenting, but some do. You should have a comment at the top stating the date it was authored, who by, when it was last edited and who by. A very brief description of the file and what it contains. I refer back to the Index concept mentioned in Step 5. This is getting back to basic software engineering principles. An average coder with strong personal software process skills and who writes maintainable code is far more value to your organisation than a guru running solo. Other people have to be able to access and understand your work.

Its necessary to comment bug fixes and particularly difficult problems that you overcame. This allows you to quickly find the cure again if you need, but it also gives you some protection against inadvertantly removing obscure fixes at a later date. Not everything is obvious to everyone.

Also, if a third party has access to the stylesheets they need to comment every single change they have made and provide a date. This needs strict enforcement.

Step 8: Decide How Much Size Matters

This feeds back heavily onto Step 4, but you need to decide this from the very beginning. At what cost are you willing to squeeze out space in your stylesheet? Is your ultimate aim to create the slickest most complex CSS files or to create the most understandable files (this includes using short class names or meaningful longer ones). This decision should be made at the strategic level.

Step 9: Settle on Naming Conventions

Another maintainability issue is naming conventions. The less consistency you have the harder and more expensive it is to work with these stylesheets. Do you use underscores or dashes? Do you start with lowercase and capitalise the first letter of new words? Do you use semantic meaningful names (best practice) or do you use names like left, right and red? Or k_bat and i_col?

Step 10: Whether to Validate Stylesheets

Even if you allow invalid stylesheets by using proprietary rules you should still require the W3C CSS Validator be used for every file. This will pick up any minor syntax errors. Ultimately being on the same wavelength about this priority can save arguments down the track.

Step 11: The Pros and Cons of CSS Reset

More recently I’ve been pulled into the fold of using CSS Reset at the top of my files. While many of the rules in the reset aren’t applicable on every project they are ultimately a small amount of bandwidth at the benefit of solving a number of cross browser inconsistencies. Yes you can solve these individually as you go - but the Reset saves time. And it provides confidence that you’re starting from a reasonably level playing field on the browser level.

Step 12: Whether to Compress Files

GZipping your CSS might be an option worth considering on larger sites. Compression can reduce size by up to 80% from the original. This is definately a strategic question, too.

Ultimately, It’s a Business Model

While more could be added to this set of guidelines the important thing to take away from this article is the strategic necessity to maintain consistent authoring. If you hire external contractors or employ new staff you should be able to hand them a strategic document (supported by management) that says this is how we author quality maintainable software. And, at the same time, these should be rigidly followed in the trenches so that external contractors who refuse to follow conventions simply aren’t rehired next time around.

Currently many teams develop web software using a house of cards ad-hoc strategic environment. We do this professionally and its about money. Yes its an art and we’re obsessives but web development is about providing Return on Investment (ROI) for ourselves and the client.

These guidelines will save you money, make your CSS strategy more competitive and provide a superior professional product.

This entry was posted on Saturday, August 2nd, 2008 at 3:42 pm and is filed under business, css, web standards. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.