Yes, it takes some time and discussions between the disciplines but you can win so much time in the future if done right. Doing stuff right depends on some crucial things:

• Work interdisciplinary and as (almost) equals. It’s easy to say what you think out the whole plan yourself, but if you do that, others are not inclined to think with you. Each new idea becomes just another bump in the project instead of a good contribution to a discussion to get a better understanding of a problem. By putting your problem on the table and make team members real team members, you get a real discussion. And a better product in the end
• Make your work public. You also get a whole other situation if you know that other people (clients or the community) are keeping an eye on you. In the positive sense of the word, that is. You have to think (just like Twitter) what is really useful outside your little bubble. And you might get good feedback to make your code even better/stable/useful.
  By thinking hard how to make stuff usable for the outside world, you’re instantly making a very usable and learnable tool for anyone who’s going to work at your firm.
  Making open source software could also motivate people. They’re not just working hard for the company anymore, they’re also working on something that can also be useful outside of the company and the greater good. That can be the motivation to work a more on it outside work time.
• Results before deadlines or budget. Ok, projects with limitless budgets aren’t realistic. But making reusable code or applications without keeping an eye on its usability or not even testing isn’t realistic either. To get quality reusable code you do not only need to write it, you have to think it out, write it and rewrite it and rewrite it. If you’re not prepared to do that, just save yourself the trouble.
• Continuous testing. Don’t wait until the very end of the project to measure its quality. You cannot remove the concrete slabs below an ill-constructed house either. Everybody has to at least check the end result of the finished component before moving on to the next target.
• Reusability is epic. Don’t kid yourself: Most of the stuff you do now has been done in the past as well. Talk with designers, programmers and developers to aim for reusability while preventing that all websites start to look the same. Getting some framework that works for everybody is everybody’s priority.
• Keep it simple. Some projects need solid plans. Others don’t. Some stuff does not have to be written out in threefold as long as the basics are known and the outer borders have been drawn. Be wary if the 5th version of the plan is mailed in PDF form to all team members, project time already gets out of hand and no real work is done yet.

No related posts.

But since we live in the real world we really need filter styling. At least for now anyway. And yes, Less can handle MSIE filters although you may have to dig a bit deeper. The following mixin works in .Less (Less for ASP.NET):

.gp_opacity(@opacity: 0.5) {
	opacity: @opacity;
	-ms-filter: ~"'progid:DXImageTransform.Microsoft.Alpha(Opacity=" @opacity*100 ~")'";
	filter: ~"alpha(opacity=" @opacity*100 ~")";
}

Happy programming!

Related posts:

1. Cool cross-browser styling with CSS and IE’s filter

But with Less the CSS code gets parsed, combined and most likely minified. With Less or Sass you cannot trace back styling via your developer tools in a simple manner.

At the moment I’m building a HTML/CSS/JavaScript framework based on Less and ASP.NET. Because that framework will get a solid code convention I’m convinced that I can keep the issue of not being able to find the right CSS code to a minimum. But I’m pessimistic about the solidness of Less-code that is written uniquely for each website. Such code does not get the same tender love and care as the reusable code of a framework. Furthermore: it is often bound to deadlines and budgets which may lead to sloppy code.

In worst case scenarios the Less code becomes a black box that magically generates styling but cannot be edited because it hides its inner workings. The only way to edit the style is to add an exception at the end of the Less file and maybe adding an !important.

In short: the ability trace back code styling might get close to null.

My personal guidelines for Less

Make your styling findable

Use a code convention which enables you to trace back the original Less code. As an example: I’m creating a lot of components for a framework. Each component is a block of code written as a nested rule like this:

/**
 * Root styling for menu
 */
.gp_menu {
	ul {
		background: @gp_colorLow;
	}

	> ul > li > a {
		display: inline-block;
	}
}

In my personal code convention I committed myself to make only one level in a nested rules block and to use a unique root selector. So if I see in Firebug a selector like .gp_menu > ul > li > a, I can search in my project for .gp_menu { to get to the right nested rules block. Then I can use > ul > li > a to finally get to the right point in the code to edit.

Now the code you see up there is just the base styling. It needs more styling to make it a real menu. In my framework there are many components that share the same basic styling. Let’s add some code to create a horizontal and a vertical menu:

/**
 * Horizontal menu
 */
.gp_menu.gp_menu_typeHorizontal {
	min-height: 0;

	&:after {
		.clear;
	}

	/* ... lots of more styling */
}

/**
 * Verical menu
 */
.gp_menu.gp_menu_typeVertical {
	li.gp_active > ul {
		display: block;
	}

	/* ... lots of more styling */
}

Now if I open up my Firebug and find a selector like .gp_menu.gp_menu_typeVertical li li, I know I have to search for .gp_menu.gp_menu_typeVertical {. This way code conventions helps me to find the right Less code.

Be cautious using Less in quick ‘n dirty projects

Deadline pressure can easily make a person write bad, unstructured code. With Less it gets even worse: bad, unstructured code and really hard to debug. You should think twice about letting that intern build the base styling of a website, but think three times if you let that intern write Less code for a website. You will be the one who has to debug it at the end of the project!

Better like your Less parser, it might be your only one

Do you like your Less parser? That’s good, because your Less code might not get parsed by other Less libraries. I’ve written my Less code with .less for ASP.NET and tried to parse my code with SimpleLess. It failed to compile the whole bunch without a proper error message.

Part of the problem is that a bug in CSS (or differences in interpretation for that matter) are ignored in browsers, but Less parsers will throw a big fat exception. Exceptions can be a good thing but not if it differs between parsers. Maybe Less has to be adopted as a standard by the W3C?

Having a solid standard would be a good thing since Google just presented their own take on Less CSS with Closure Stylesheets. They already bended the informal JSDoc spec towards their own standards with previous Closure releases.

Update: LessCSS LinkedIn group

I created a LinkedIn group for LessCSS.

Related posts:

1. The last resort in CSS debugging
2. CSS debugging
3. Useful FileZilla tips

How to do mobile redirection

Mobile website != desktop website

In many cases the mobile website just contains a subset of the content that’s available on the main website. That’s because mobile websites are made with the mobile context in mind. This results in very short texts and location based services.

Moreover: there just isn’t much web traffic from mobile devices if you compare it to the traffic that browsers on traditional computers generate. So many organizations don’t see the necessity for a mobile website that is as comprehensive as the desktop variant.

This means that if you would land on a some web page, there will most likely be no mobile equivalent of that content. So there’s no reason to redirect the user. Unless mobile devices are likely to crash.

Users can redirect themselves

In the early days the differences in capabilities between handhelds and PC’s was very large. But now those devices are smartphones and are powerful hardware. Users can now choose between the predictable security of the main websites and the usability of mobile websites. It’s, bar some exceptions, a matter of preference now, not a necessity.

You can get away with redirecting users to a mobile website once, but don’t redirect them all the time. A user that visits the main website with a smartphone most likely just prefers the main website, so don’t keep him away from the content you want to disclose on the web.

Even better than redirecting: just add a link to your main page to your mobile website and vice versa. That’s a strategy that works as long both websites can be viewed on a smartphone.

Related posts:

1. Extending media queries with JavaScript

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

DEL is your friend

Those cases happen rarely but when they do, I always resort to a tested and tried technique: isolate the problem by removing or commenting all unneeded markup. Isolating the problem may take some time but when you have a web page with a minimum of HTML while keeping the styling bug intact, you get in most cases the bug fixed in no time.

Why does isolating code work so well? Well, most of the time you can find styling bugs by experience, but when you’re stuck, every bit of styling on a tag becomes suspicious and that’s just too much to test. The bug becomes a needle in a hay stack.

Removing the easy way

The best way to remove blocks in a page is by just adding a display: none to its styling via a developer tool like Firefox’s Firebug, Opera’s Dragonfly, Webkits developer tools or IE’s Web Developer Toolbar. Just cut away big blocks and each time you remove something, you test if the bug still persists. You continue until you find the block that is triggering the bug. Most of the time you’ll have to continue the same technique of removing bits of code within that block until you can isolate the problem.

Hiding a block by adding a 'display: none'

Removing a block of HTML completely

Removing the source code

Sometimes it’s better to have direct access to the source HTML than doing temporary changes in the developer tool. But if the HTML is (partly) created server side it’s hard to easily remove stuff. In those cases when I’m really desperate, I request the HTML source from the browser and save it in the directory the original web page resides. Then I can make dramatic changes to the code and test in multiple browsers without affecting the site itself.

Is this an efficient way of debugging? Definitely not, but sometimes you just need to do it. It happens to me once or twice a year or so and by debugging that way I always managed to find the root of the problem.

Related posts:

1. CSS debugging
2. Tips for using and debugging of Less CSS code

For example: progressive enhancement in practice means that if you want to implement rounded corners, you’d use the border-radius style instead of a stack of images of rounded corners. But what if rounded corners are one of the corner stones of the corporate design of the client? Loads of users on IE7 and IE8 would miss that recognizable feature of that corporate design.

The design choice of rounded corners are sometimes a matter of taste, but most clients care for their corporate identity. So if you are ready to slaughter someones design in IE7/IE8 with progressive enhancement as your alibi, make sure that the features that will be missed in those browsers are not an important part of their corporate identity.

Related posts:

1. Do you create your design in Photoshop or Notepad?

Download Estate Developer Tools

Features

• Compare page with original design fast: You can compare the current page with an image of the original design within the browser.
• CSS reload: Reload the stylesheets without reloading the page. Extremely useful when designing websites with many Ajax calls.
• Console.log fallback: If you use clog(), debug messages will be routed to console.log() if available. If not (eg. you’re developing in IE), the message will be printed in a log box in the web page itself.
• Autofill and test forms: Auto fill forms with text that might cause errors like non-western characters, malformed HTML, JS injection and SQL injection. Autofill also works with the new HTML5 form fields.
• Timer: Do performance test by checking how long some operation takes.
• Works in: IE6+ and all recent versions of Firefox, Chrome, Safari and Opera. I did not check all possible browser versions, but it should work. let me know if you have problems with older browsers. The developer tools do not work in IE’s Quirks mode, but that’s something you should avoid anyway.

Quick overview

Sorry for the bad sound quality.

Installation

Step one is to download the tool. If you unpack the zip, you’ll find example page in the (what else) “example” directory.

Open the file called “index.html”. The developer tools are loaded just before the closing body tag: <script type="text/javascript" src="devtools/javascript/estate-devtools.min.js"></script>.

If you want to change the library to your own needs, you can load the source code instead. It’s in 4 seperate files that are in the same directory: Estate.js, Estate.Develop.js, Estate.Develop.FormTester.js and Estate.Develop.DesignTester.js.

After the library has been loaded, you can add items to the top right menu like this:

	Estate.Events.AddEvent(window, Estate.Develop.ToggleVisibility.Init, "onload")
	Estate.Events.AddEvent(window, Estate.Develop.ReloadCSS.Init, "onload")
	Estate.Events.AddEvent(window, Estate.Develop.FormTester.Init, "onload")
	Estate.Events.AddEvent(
		window,
		function() {
			Estate.Develop.DesignTester.Init({
				designAnchor: document.getElementById('DesignTester'),
				xOffset: 10,
				yOffset: 5
			})
		},
		"onload"
	)

The example above will most likely be enough in most cases. The only thing you might have to configure is the Design Tester. That’s because the design image needs to be positioned relative to the main body of the page. Therefore you need to define an anchor by supplying a reference to an HTML element and define the optional offset.

You can also use jQuery to supply an HTML element like this: designAnchor: jQuery('#DesignTester')[0]. The Form Tester is also configurable. Please refer to the object reference for more information.

To install the Estate Developer Tools into your own website, you’ll have to copy the JavaScript code at the bottom of the page to your own and copy the devtools folder to the root of your own website.

After that you only need to create PNG files of the original design and save them in the folder/devtools/design-images/. If a page is loaded, the Design Tester looks for a PNG file which file name resembles the URL of the page. If that image cannot be found, the Design Tester will asks for that file either by printing a message in the console log or in its own fallback log box in the page. You just have to look up the right file and rename so that the Design Tester can pick it up.

Helper functions

Some functionality is not included in the menu

console.log fallback

After the library has been loaded, two global functions are available: clog() and dlog(). You use clog() to send a string to console.log() if available. If console.log is not available, the debug message will be printed in the log box in the website. If you can also choose to always use the log box of the Estate Developer Tools by calling dlog().

Timer

If you you want to optimize, you can use the timer to see how much time JavaScript needs to complete an operation. You just create a new instance of the timer object, set an ID so you can distinguish multiple alert from an another, start the timer, run some function or lines of code and the stop the timer. By stopping the timer, you’ll get a message how much milliseconds the operation costs. Here below is an example:

var oTimer = new Estate.Develop.Timer()
oTimer.SetID('Your time to response')
oTimer.Start()
alert('Press "ok" to see how much time it took to respond')
oTimer.End()

Reference

All public objects and methods have been documented with JsDoc Toolkit. Read the documentation.

Adding more tools

It’s possible to integrate your own developer tools in the menu of the Estate Developer Tool. This code will create an extra menu item and runs some code when a user clicks on it:

/**
 * @namespace Creates extra menu
 */
Estate.Develop.ExtraMenuItem = ( function() {
	var menuButton

	function doSomething() {
		dlog('Menu item pressed')
	}

	/* START PUBLIC */
	return {
		/**
		 * Initializes extra menu button
		 *
		 * @example
		 * Estate.Develop.ExtraMenuItem.Init()
		 */
		Init: function() {
			menuButton = Estate.Develop.Menu.AddMenuItem('Extra item')

			menuButton.onclick = function() {
				doSomething()
			}
		}
	}
	/* END PUBLIC */
})();

It’s also possible to attach a keypress event to it

/**
 * @namespace Creates extra menu
 */
Estate.Develop.ExtraMenuItem = ( function() {
	var menuButton

	function doSomething() {
		dlog('Menu item pressed')
	}

	function pageKeyPress(KeyID){
		dlog('KeyID: '+ KeyID)
	}

	/* START PUBLIC */
	return {
		/**
		 * Initializes extra menu button
		 *
		 * @example
		 * Estate.Develop.ExtraMenuItem.Init()
		 */
		Init: function() {
			menuButton = Estate.Develop.Menu.AddMenuItem('Extra item', 'Press any key')

			menuButton.onclick = function() {
				doSomething()
			}

			// Handle global key events
			Estate.Events.AddEvent (
				document,
				function(e) {
					var KeyID = (window.event) ? event.keyCode : e.which;
					pageKeyPress(KeyID)
				},
				"onkeypress"
			)
		}
	}
	/* END PUBLIC */
})();

No related posts.

What are media queries

To explain what media queries are, it’s best to start with the standard media types. Media types were introduced as part of the CSS2 specification way back in 1998 and is supported by all major browsers. The most common are “screen” (desktop PC’s), “handheld” (mobile devices), and “print”. Here’s an example of how to link a CSS file to a media type:

This looks pretty straightforward and it is. But most mobile browsers don’t consider themselves “handheld” when choosing a CSS file. Devices like iPhone, Android and Nokia behave like a desktop computer and select the CSS that’s reserved for the “screen”-devices.

This was in some way a logical step, since most websites don’t have a CSS file for handheld devices. The drawback is also very clear: You cannot cram a web page optimized for desktop monitors in a 2′ handheld monitor without paying a price. Usability suffers. Users are given crutches like the ability to zoom in to a specific part of the page, but that’s like watching TV through a keyhole.

To address this problem the W3C came with media queries. Now you can check properties like screen size and resolution. So now you get something like this:

Now we have all our ducks back in a row. If the browser width is larger than 480 pixels, it will select “screen.css”. If the width is smaller or equal to 480 pixels, it will go for “handheld.css”. We keep our CSS link with media="handheld" as a fallback for handheld devices that don’t do media queries, most notably IE Mobile and Blackberry’s browser. Checkout PPK’s compatibility table to see which browser does not support Media Queries yet.

Filling the gaps

But this still is not enough to have your site render well in all browsers. IE and many older browsers do not handle the new media queries.

Some sort of solution was proposed on ALA, but that technique requires an extra CSS file called antiscreen.css that cancels some of all styles that were created in the screen.css. Most of the websites I make just have too much CSS styling to make that technique usable.

JavaScript can also detect the screen width, so I decided to use it to help browsers in choosing the right CSS. The script I created also checks the screen width after a window resize, just like Media Queries. Just open the demo and you will see that the page will switch to the mobile stylesheet if the window gets too narrow. Even in browsers that don’t support Media Queries (yes, I’m looking at you, IE!).

How it works

In the demo the script expects that if Media Queries are supported by the browser, a div with the class cssLoadCheck should be 100 pixels in width. To check that it this is true it will insert a div with that class into the DOM, check its width and then removes it from the DOM again. If the width of that test div isn’t 100 pixels we know that Media Queries are not supported and that JavaScript has to supply a CSS file depending on its width.

Each time the pages refreshes it removes the dynamically added link-tags in the head and adds new ones.

Possible improvements

This is just a simple script and there is lots of room for improvement. I could also built a script that figures out itself what CSS to load by looking at the media query statements in the markup. The current state of the script is good enough for my needs, so I’ll keep it like this for now.

Related posts:

1. Codeview update
2. Redirect to a mobile website
3. Codeview, a new template for JSDoc Toolkit

“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