Building Cascading Stylesheets for the Enterprise

The way and effort required for building Enterprise Portals varies greatly from the world of fancy web 2.0 designs. This is why building cascading style sheets (CSS) for Enterprise portal has its own special issues and considerations.

Big enterprises often build huge websites which evolve over time. This implies that long after the web design agency has finished its design (and is no longer there to support developers), the website continues to grow, adding features and new content blocks on the way. As most programmers will acknowledge: code complexity and flexibility decreases after a product is released. This is often caused by less experienced CSS personnel or because the original code just wasn’t designed to be that flexible.

Building for the future

One of the most compelling accomplishments for a programmer is to craft beautiful code. Besides being an great accomplishment, it is also a common pitfall as the line when to stop making code even more beautiful is a thin one. In CSS however, there are certain best practices you should follow when building enterprise style sheets:

Utilize CSS (Grid) Frameworks

CSS Frameworks are created by the gifted CSS gods who have the knowledge and time to build layouts which work in every browser! These frameworks are built for reuse and have great flexibility. Starting with a CSS Framework means not having to build a lot of elements, which is kind of like cheating (and you’ll like it just as well)!

CSS Grids frameworks are also an excellent way to bring flexibility to your layouts. Because you are building on this solid foundation, switching a layout from three columns to four columns can be as easy as switching a class!

I would recommend taking a look at the Yahoo Grids CSS and their other CSS goodies (reset, base, fonts). Besides quality code, Yahoo YUI offers great documentation and training resources.

Flexible components

After you have defined a grid (using your favorite grid framework) you come down to styling the components which will live in inside the grids. When building these styles you should take the following into account:

• Use the cascade with care — If you style component to explicitly (div#main div.contentmiddle ul.news h3.title) you are trading time for flexibility. Do your best to minimize selectors.
  Only use ID’s if you really have to. ID’s are “stronger” selectors than classes. If you have to change such a selector, you end up specifying ridiculous selectors (html body#main div#container div#crap!) or using !important which decreases maintainability as well as flexibility
• Don’t use explicit heights — Sooner or later that one heading which was never supposed to be changed, now spans two lines instead of one. And suddenly the gradient background is to short.
• Don’t use explicit widths — Build your component’s so they’ll fit in any grid cell. You never know if that one component is

Build templates for developers

Like it or not, your designs will probably be implemented by backend developers who do not passionately check for XHTML and CSS validation issues. So the task is up to you to provide them with everything (and more) to make sure the layouts turn out you build them and won’t fall so easily.

Programmers are lazy by nature. If they can steal/copy code from somewhere, they’ll probably do. You can put this behavior to your advantage by providing developers with easy copy-past examples of your layout.

To correct backend developers to write valid markup, you can also use diagnostic styling. Diagnostic styling is a CSS file which contains selectors which highlights basic markup faults. Styling these faults so horrible (think fuchsia meets comic sans) causes instant bug fixing, without taking any of your time!

Your Development CSS IS NOT your production CSS

The more styles you get the harder it is to find anything. To counter this problem, separate your styles in different files. I like to separate my CSS files like this:

• reset.css — reset all browser’s defaults styles, letting you do the job
• grids.css — defines the main layout parts
• fontcolor.css — generic font size, element styles and colors used site-wide
• buttons.css — all buttons used, aim for consistency
• forms.css — each sub-site will use web forms. Know this and build a forms “framework” which is flexible enough
• moduleX.csss — create a separate CSS for each sub-site. Doing this helps find bugs and allows for removing a complete CSS file if the sub-site is no longer among us.

For development purposes, create a file merging all these files together using @import statements. When it is time to release your styles, append them together in one big file and compress it. This way you minimize file size and the amounts of web requests a user has to make to visit your site, boosting performance!

Know thy target framework

Knowing which backend framework will render your website’s markup can pose additional considerations. A problem I have seen on ASP.NET projects is the inability to set ID’s on elements. This is caused by the underlying framework and therefore cannot be changed easily. If you know this in advance, you can easily create styles with minimal ID’s, saving you time to spend reading up on your blogroll!

I hope this helps you build your styles for the next big enterprise portal project you’re on. If you have any suggestions, please let me know and drop a comment!

Tags: css, Yahoo

This entry was posted on Tuesday, March 17th, 2009 at 19:54 and is filed under webdesign. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.