Problems with my current codebase

Well, I already have a codebase, but it has some problems. The important one is that it only covers the very basics. That’s because designs can be very diverse and as a developer I want to stay true to the design. So it’s hard to build a codebase with grids and blocks if all design differ from eachother.

Another problem major issue is something I have more control over: the codebase and the documentation is a bit scattered. The last problem I have is that I have no demo page of my standard CSS code, so there’s no easy way to check the template on browser compatibilities.

Now my jQuery plugin project has reached version 1.1, I had the time to do some thinking about a new codebase that would be solid, extendable, easy to deploy and would replace all other codebases and documentation.

Let me make it clear: this article is about my considerations about building a solid framework for myself. It may not apply to you and my ideas not unique either. It still may be helpful for you to get an idea of what sort of codebase you need.

Existing examples

The most important thing about a codebase is to decide how to set it up and how to store it. I like the way open source grids like Grid960 and YUI have organized their code into little reusable bits and have created a demo and test page for each and every component.

I must admit: I hardly ever used these grids. Most of those grids talk the language of the web developer, not of the designer. And the designers I know don’t have to limit themselves to a 24-column grid system. Not to mention the designers that are totally ignorant of such a system and whose task is to design a website and mail the Photoshop file to some other company that has to build it. Although I have my reservations towards grids, I like the way these codebases are organized. It can serve as a good Blueprint for my own codebase.

I also get my inspiration from Nicole Sullivan’s talk on Object Oriented CSS (OOCSS). OOCSS basically means that you build your components in such a way that they become extendable objects. Just like in real object oriented programming. Just have a look at her talk about OOCSS on Yahoo! Developer Network.

Prefix classes

By adding a (relatively) unique string before the name of the class you have created your own CSS namespace. It will minimize any interference of other CSS styling that is not part of your own code. Some real life examples can be found in the code that is generated by the CMS systems I have experience with: Sitefinity and Sitecore. The CMS Sitefinity for example prefixes all CSS classes with “sf_”.

Grids, blocks and text

All CSS code will be split into different categories that work relatively independently of each other. Until now I can come up with 3 of them.

Grids

Grids are the frameworks of placeholders in which we put our content. You know: header, visual, column1, column2, column3 and footer. There are lots of grid templates around like Grid960 and Blueprint. My view is that those templates only work if the designer agrees to work within the limits of that framework. My ambition is to write a framework that makes my work easier while still being flexible enough to keep the designers happy.

Blocks

There are as many block as the designer can come up with. I think it will be a real time saver to talk with the designer and write down all the types of blocks he thinks he’ll like to use often. Or even better: just open the last 20 or so web designs he/she made and destil the common blocks and its common features. like menus, news article lists, homepage spotlights, etc. Finally you create basic blocks of it in your template system.

Standarization is not always popular with designers but if it means that projects can be created cheaper there may eventually be budget left to build cool stuff. At least, I hope…

Text

Basic text styling is also a relatively independent component in CSS code. You always define a basic font color, family, size and line height that serves as a base styling for the whole websites. More specific text styling in blocks should be kept to a minimum and preferably relatively to the base text style. So if you have a base style of font: 1em/1.5em normal Arial, sans-serif, you ideally should style a header in a block like this: font-size: 1.5em; line-height: 1.2em;.

Although font-weight is not something you can set relative to a base style, it’s not likely that it will look ugly in combination with some design if you add font-weight styling to a block. Setting the font-family in the styling of blocks on the other hand will most likely interfere with design, since designs tend to depend heavily on a particular font.

Create base templates and extend themes

The code for each grid system and each block will be stored in a seperate base CSS file. Each grid or block can be extended with extra themes or styles. Each style extension will have its own CSS file and presumes that the base file is already loaded.

Optimizing CSS

Having all code seperated in small snippets is great for maintaining an overview. As long as you can see what a CSS file does by looking at its filename, its will be easy to add and extend styling to a website.

The template code is not optimized for speed, though. If we don’t do anything about the fragmentation, the server will have to load a bunch of little CSS files. It’s important to stress this: It’s not just the total filesize that matters, each http request costs time. Check out YSlow if you want to know more about this and if it affects your site.

YUI

That’s why all CSS in the website has to be exported, merged and its code minified to one single CSS file. Normally I use YUI compressor for it.

Less

But you can do more than just minification. Less is a system that extends the CSS syntax with stuff like variables, nested rules and mixins. Less was originally built in Ruby, but there’s also an ASP.NET port. I hope it will help me create very flexible grids.

By exporting CSS into optimized code, you can focus on making the most readable CSS source file because all comments and spaces in the code will be removed in the end. This is also what I do with JavaScript code and certainly will continue to do.

Related posts:

1. Too advanced CSS selectors
2. The last resort in CSS debugging
3. Tips for using and debugging of Less CSS code
4. Crucial stuff for your company’s internal projects

“There are differences between class and id. Class attributes should be used when you have more than one item on the page with the same class value. Conversely, id values have to be unique to a page.

When I first learned this, I figured I’d just always use class attributes so I wouldn’t have to worry about whether I was duping an id value. However, selecting elements by id is much faster than selecting them by class, so you can hurt your performance by overusing class selectors.”

Huh? I never use ID’s in CSS selectors, but I never experienced slow rendering either. I wanted to test if it’s stupid not to use ID’s.

First I wanted to see if it was even able to create a CSS that was hard to parse. Google has a nice article about writing efficient CSS selectors, so that seemed like a good start before setting up a test. In short there are 2 things that make a fast CSS selector:

• Make rules as specific as possible
  This means that div.content is faster than *.
  You have to be especially specific with the rightmost selector, since the browser reads CSS selector from right to left.
• Avoid (large) descendant rules
  An example of a descendant rule is div.content div.column1 div.columnHeader h2. Descendant rules are less efficient than rules with a single selector, like h2.

Test 1: setting up extremely inefficient CSS

The most inefficient selector by far is *. Combined with large descendant rules you get extremely inefficient selectors:

* * * * * * * * * {
	background: #ff1;
}
* * * * {
	background: #ff2;
}
* * * * * * * {
	background: #ff3;
}

I created a CSS file of about 20KB in size with 3600 asterisks characters (*). I combined it with a very large HTML file (1MB) with 9000 opening HTML brackets (<). Because I only wanted to test the CSS rendering, I added the following JavaScript to be able to load the CSS file on my local computer after the page was loaded.

	Load CSS
	

Results Test 1

All tests were done on my computer (Vista with Intel Duo Core @ 2.4GHz) except for IE7 and IE6. IE7 was tested on a Vista machine with Intel Core Duo SPU @ 2.67Ghz. IE6 was tested on my machine with Virtual PC and on a PC with Windows XP SP3 and a Pentium 3 CPU 3GHz.

The results show that browsers freeze for at least 2 seconds in order to render the CSS. So it is possible to screw up your rendering, but you really have to make an effort for it with large HTML files and unrealistic CSS selectors.

Test 2: setting up a more realistic scenario

In this test I created a more realistic scenario. I took an existing CSS file and altered it until it was 113KB in size and contained about 1050 selectors. I changed the CSS rules until the bulk of the code looked like this:

.Homepage .containerText {
	position: relative;
	margin: 15px auto 0px auto;
	width: 960px;
	background:#ffffff;
}
.Homepage .containerText .containerLeft {
	float:left;
	width:450px;
	padding:10px 20px 45px 10px;
}
.Homepage .containerText .containerLeft p {
	margin:0px 0px 5px 0px;
	color:#414a49;
	line-height:1.286em;
}

So most of the code in the CSS file consisted of descendant selectors with classes and hardly any tag names. The corresponding HTML page was also created from existing code and copy-pasted until the file was 107KB in size with almost 600 opening HTML brackets (<). Now we have a relatively large HTML and CSS, but not unrealistic. Once again I tested it in different browsers:

Results Test 2

All modern browsers responded so fast that I couldn’t really notice it needed rendering time. This means that the CSS file does not need any optimization by utilizing ID’s. The only browser that could profit from more efficient CSS selectors is IE 6. But since I don’t have to support IE 6 anymore, it’s not worth my time.

Conclusion

Writing fast CSS certainly will help some browsers on slow PC’s. But that is a minority of the users. So unless you have special requirements for your website, you’ll be better off focusing on writing logical, maintainable code than trying to get the browser to render a few milliseconds faster. There are some considerations though:

Being more specific

A few years ago I switched from writing .foo to writing a.foo. Adding the tag name in the selector gives me a better idea what I’m styling. Now I know that this coding style is also faster in rendering.

Descendant selectors

Descendent selectors (using more than one element in a CSS rule) are inefficient in rendering, but I won’t give that up. I like to be specific about what element I want to select in CSS. I rather write div.column1 div.article span.date than span.date. The latter is more efficient, but that only works with very small websites because only then you’d still have an overview of the all classes that are in the HTML code.

When I write JavaScript code I try not to ‘pollute’ the global namespace. I try to do the same with CSS by using descendent selectors.

If you need faster rendering, you could alter descendant selectors by making one class that incorporates the whole path. So you’ll get span.column1_article_date instead of div.column1 div.article span.date. Although it would render faster, it also has some drawbacks. Renaming a class afterwards is tedious work, the class names can become very long and the classes can be used outside it’s intended containers, so a class called div.column1_article_date could be used anywhere in the DOM and not just inside div with the class column1.

ID’s and JavaScript

I do use ID’s by the way, Not in CSS though, but for JavaScript for these reasons:

• Specific elements can be easily accessed in plain JavaScript with getElementById.
• If an element has an ID, I can be pretty surre that there is a bit of JavaScript attached to it.
• Using ID’s in your jQuery selectors makes the selectors less dependent on the current HTML structure. It’s easy to break existing jQuery selectors by removing a class in the DOM.

Related posts:

1. Too advanced CSS selectors
2. Hack: how to enable :first-child in IE6