CSS Tips and Making Efficient Web Interfaces
I was recently asked to find a somewhat comprehensive listing of CSS tips. Instead I decided to start pouring it all down in a post for later reference. I won’t really go over the basics, but a decent resource to get started in HTML and CSS can be found at http://htmldog.com/. I found them to be a decent starter kit for people. Now onto some ways to improve the way you write CSS.
Avoid Unnecessary Chaining
For example if a style references the id of an element, be sure to not add unnecessary information about its ancestry.
#page #header #navigation {} could just be #navigation{}
Since we’re already using an id for the element, there is no point to give an ancestry.
Caveat: When I want to change the navigation on a particular page I could do the following.
#home_page #navigation{}
Use Specific Class names
The further down the DOM tree you get the more specific the class naming should get to avoid possible conflict. I have adopted chaining the tree inline as it involves fewer lookups. Also, the style declarations are read in reverse order from right to left, having just one class reduces the amount of pruning involved.
Instead of using something like #header #navigation .button we can describe the item using one class: .header_navigation_button
Use relative then absolute positioning, more than you’d like to
A lot of browser conflicts or oddities can be resolved using absolute positioning. Instead of relying on placements using floating or margins often times positioning an element in a relative block will fix spacing issues that might arise across browsers. Examples of this are buttons with set icon sizes, header content, etc… Since placing things absolutely takes it out of the flow of that element, you don’t have to worry about how it will affect the other sibling elements. Then those siblings can be “fixed” using proper padding or margin.
Allow Block Elements to Fill Their Space Naturally
A huge problem for a lot of people when it comes to layout is how different browsers treat their width/height and their padding and border. Sometimes the border and padding are considered internal or sometimes external to the block element. To avoid this on elements where you need to set the width, do not use padding or border on the left or right, and vice versa for the top and bottom. Often times this will destroy your layout. Make sure that layout blocks retain the size you want them to and avoid overloading them with styles that will cause them to generate various widths and heights on different browsers. A blocks natural inclination is to fill the space available (e.g. width: auto;) much like a liquid.
Another situation you won’t want get in when styling a layout is to use percentages with a child element, where the parent has padding. For example setting the width of the child to 100% width and the parent to having a padding of 20px all around, might lead you to think that the child element will fill the area inside the padded area to 100%. However, what this actually means is that the child element will be 100% of the width of the parent and start from the (20, 20) mark of the parent element, and spilling outside of the parent block. A better solution would be to just let the child block default to automatically assign its width and height.
Speed Considerations
It is also important to consider the efficiency of your CSS, and the point behind using less verbose selectors and specific class names. For speed, it is important to keep in mind that the more selectors you use in the style declaration the less efficient the selector is. The best you can do is to avoid large chaining. It is also important to redcuce the number of elements on the screen at a given time, thus making the DOM faster to traverse. The less steep the tree the faster the interface will be. The practice of having to keep everything simple is in a constant struggle to meet the needs of the design, as sometimes the design will require more elements on the screen than is practically needed; creating more overhead.
Other ways to improve speed are to add inline styles to elements. Inline styles will override any styles in a stylesheet with the exception of styles with the !important declaration. A good example of inline styles are elements that either require dynamically generated placement, such as the slickgrid or its spiritual derivatives.
Garbage Collection
This is related, but not exactly on topic. But it is important to have a rudimentary form of garbage collection for your DOM elements. Make sure that when you’re done with an interface you take it off the view. If it’s more work to update the styles and content than to re-render a scene than it is advisable to just start from scratch and redraw it. This problem is a lot more obvious on sites that rely on ajaxian interfaces. For example, I was visiting twitter the other day and had left Firefox on overnight. The next day my computer was running insanely slow, and I traced it to twitter’s site. I counted how many DOM elements they had on the screen and it came out to roughly 200,000. I then refreshed the site and counted the number of elements on the page this time: approx. 600. Good websites can typically show their entire front page in about 500 – 600 elements.
On load Grooveshark uses about 550 elements. The real killers are content dedicated to displaying both large amounts of data and large amounts of “visual” data. To avoid that, things like the queue, pages, and lightboxes are all in charge of their own garbage collection. If it’s not going to be used or seen in the foreseeable future, kill it!