Common Mistakes for CSS-Designers to Avoid

Common mistakes for CSS-designers to avoid?

Not using a reset file.

"The goal of a reset stylesheet is to reduce browser inconsistencies in things like default line heights, margins and font sizes of headings, and so on."

- Eric Meyer, Meyerweb.com

What is the best method for tidying CSS?

You might want to encapsulate your css within a more formal CSS framework. You can create your own custom framework but there are some useful open source css frameworks such as yahoo's YUI and Blue Print CSS
http://www.blueprintcss.org/

The nice thing about this approach is that it leverages a lot of effort to fix the cross browser issues around fonts and layout.

Depending how far you go you may have to extensively touch the existing markup. Depending on how large your site is I would try to incrementally adjust styles and migrate them over to the formal CSS framework. Long term this will make the CSS more manageable and easily understood by other developers familiar with the concept of the framework.

Progressively try to eliminate redundant and unaccounted for styles.

I would also create a debug.css file. Take all the old style names and add an identifying style to them. For example:

.myoldstyle {border: solid 1px red};

Then you can detect where the old style is being used throughout the site. Each style should be accounted for and ported over to the new system. When a particular style in the old system has been correctly migrated to the new system you can remove (or better comment out) the identifying style from the debug.css file. You can be confident that you have migrated all the styles when the debug.css shows no side affects in the display output.

It can be a time consuming process but approaching it systematically can be helpful.

Also, you may want to start looking at your site with no css at all. Just get a sense of the logical and semantic markup of code. Having a clean HTML code base helps when debugging style quirks.

As for organization of CSS, I like to separate into basic categories: layout, typography, lookandfeel, navigation

Keep all color related information in the lookandfeel style sheet. This is where you will spend the most time trying to meet the client's visual tastes and desires. It is handy to keep that is a separate logical style sheet. The other stuff is more functional and standardized. Having this abstraction makes it much easier to isolate the visual effects of styles.

And one last tip, check out Firefox firebug plugin or Safari's debbugger. These can show you computed styles (the way styles and elements are ultimately derived as the various styles are applied) and you can tweak specific styles in real time on the fly it you want to explore the effects of a specific style change in a complex CSS system.

And most importantly, keep a separate ie.css file around. This should be the last style sheet referenced in your headers. If you need to do any workarounds for IE put them here. And only expose this style sheet to IE through conditional comments.

http://www.quirksmode.org/css/condcom.html

That is the fastest way to resolve IE 6 problems.

What's so bad about in-line CSS?

Having to change 100 lines of code when you want to make the site look different. That may not apply in your example, but if you're using inline css for things like

<div style ="font-size:larger; text-align:center; font-weight:bold">

on each page to denote a page header, it would be a lot easier to maintain as

<div class="pageheader">

if the pageheader is defined in a single stylesheet so that if you want to change how a page header looks across the entire site, you change the css in one place.

However, I'll be a heretic and say that in your example, I see no problem. You're targeting the behavior of a single image, which probably has to look right on a single page, so putting the actual css in a stylesheet would probably be overkill.

jQuery pitfalls to avoid

Being unaware of the performance hit and overusing selectors instead of assigning them to local variables. For example:-

$('#button').click(function() {
    $('#label').method();
    $('#label').method2();
    $('#label').css('background-color', 'red');
});

Rather than:-

$('#button').click(function() {
    var $label = $('#label');
    $label.method();
    $label.method2();
    $label.css('background-color', 'red');
});

Or even better with chaining:-

$('#button').click(function() {
    $("#label").method().method2().css("background-color", "red"); 
});

I found this the enlightening moment when I realized how the call stacks work.

Edit: incorporated suggestions in comments.

Managing CSS Explosion

This is a very good question. Everywhere I look, CSS files tend to get out of control after a while—especially, but not only, when working in a team.

The following are the rules I myself am trying to adhere to (not that I always manage to.)

Refactor early, refactor often. Frequently clean up CSS files, fuse together multiple definitions of the same class. Remove obsolete definitions immediately.
When adding CSS during fixing bugs, leave a comment as to what the change does ("This is to make sure the box is left aligned in IE < 7")
Avoid redundancies, e.g. defining the same thing in .classname and .classname:hover.
Use comments /** Head **/ to build a clear structure.
Use a prettifier tool that helps maintain a constant style. I use Polystyle, with which I'm quite happy (costs $15 but is money well spent). There are free ones around as well (e.g. Code Beautifier based on CSS Tidy, an open-source tool).
Build sensible classes. See below for a few notes on this.
Use semantics, avoid DIV soup - use <ul>s for menus, for example.
Define everything on as low a level as possible (e.g. a default font family, colour and size in the body) and use inherit where possible
If you have very complex CSS, maybe a CSS pre-compiler helps. I'm planning to look into xCSS for the very same reason soon. There are several others around.
If working in a team, highlight the necessity of quality and standards for CSS files as well. Everybody's big on coding standards in their programming language(s), but there is little awareness that this is necessary for CSS too.
If working in a team, do consider using Version Control. It makes things that much easier to track, and editing conflicts that much easier to solve. It's really worth it, even if you're "just" into HTML and CSS.
Do not work with !important. Not only because IE =< 7 can't deal with it. In a complex structure, the use of !important is often tempting to change a behaviour whose source can't be found, but it's poison for long-term maintenance.

Building sensible classes

This is how I like to build sensible classes.

I apply global settings first:

body { font-family: .... font-size ... color ... }
a { text-decoration: none; }

Then, I identify the main sections of the page's layout—e.g. the top area, the menu, the content, and the footer. If I wrote good markup, these areas will be identical to the HTML structure.

Then, I start building CSS classes, specifying as much ancestry as possible as long as it is sensible, and grouping related classes as closely as possible.

div.content ul.table_of_contents 
div.content ul.table_of_contents li 
div.content ul.table_of_contents li h1
div.content ul.table_of_contents li h2
div.content ul.table_of_contents li span.pagenumber

Think of the whole CSS structure as a tree with increasingly specific definitions the further away from the root you are. You want to keep the number of classes as low as possible, and you want to repeat yourself as seldom as possible.

For example, let's say you have three levels of navigational menus.
These three menus look different, but they also share certain characteristics. For example, they are all <ul>, they all have the same font size, and the items are all next to each other (as opposed to the default rendering of an ul). Also, none of the menus has any bullet points (list-style-type).

First, define the common characteristics in a class named menu:

div.navi ul.menu { display: ...; list-style-type: none; list-style-image: none; }
div.navi ul.menu li { float: left }

then, define the specific characteristics of each of the three menus. Level 1 is 40 pixels tall; levels 2 and 3, 20 pixels.

Note: you could also use multiple classes for this but Internet Explorer 6 has problems with multiple classes, so this example uses ids.

div.navi ul.menu#level1 { height: 40px; }
div.navi ul.menu#level2 { height: 20px; }
div.navi ul.menu#level3 { height: 16px; }

The markup for the menu will look like this:

<ul id="level1" class="menu"><li> ...... </li></ul>
<ul id="level2" class="menu"><li> ...... </li></ul>
<ul id="level3" class="menu"><li> ...... </li></ul>

If you have semantically similar elements on the page—like these three menus—try to work out the commonalities first and put them into a class; then, work out the specific properties and apply them to classes, or, if you have to support Internet Explorer 6, ID's.

Miscellaneous HTML tips

If you add these semantics to your HTML output, designers can later customize the look of web sites and/or apps using pure CSS, which is a great advantage and time-saver.

If possible, give every page's body a unique class: <body class='contactpage'> this makes it very easy to add page-specific tweaks to the style sheet:
```
body.contactpage div.container ul.mainmenu li { color: green }
```
When building menus automatically, add as much CSS context as possible to allow extensive styling later. For example:
```
<ul class="mainmenu">
 <li class="item_first item_active item_1"> First item </li> 
 <li class="item_2"> Second item </li> 
 <li class="item_3"> Third item </li> 
 <li class="item_last item_4"> Fourth item </li> 
</ul>
```
This way, every menu item can be accessed for styling according to its semantic context: Whether it's the first or last item in the list; Whether it's the currently active item; and by number.

Note that this assigning of multiple classes as outlined in the example above does not work properly in IE6. There is a workaround to make IE6 able to deal with multiple classes. If the workaround is not an option, you will have to set the class that is most important to you (item number, active or first/last), or resort to using IDs.

Complete list of reasons why a css file might not be working

Are you sure the stylesheet is loaded? You can see it using the "Net" tab of Firebug on firefox, or on "Network" tab of the Console of your browser.
(If 1 works) can you have a simple sample style and see whether this is getting applied (and visible in the console)?

Why not use tables for layout in HTML?

I'm going to go through your arguments one after another and try to show the errors in them.

It's good to separate content from layout
But this is a fallacious argument; Cliché Thinking.

It's not fallacious at all because HTML was designed intentionally. Misuse of an element might not be completely out of question (after all, new idioms have developed in other languages, as well) but possible negative implications have to be counterbalanced. Additionally, even if there were no arguments against misusing the <table> element today, there might be tomorrow because of the way browser vendors apply special treatment to the element. After all, they know that “<table> elements are for tabular data only” and might use this fact to improve the rendering engine, in the process subtly changing how <table>s behave, and thus breaking cases where it was previously misused.

So what? Does my boss care? Do my users care?

Depends. Is your boss pointy-haired? Then he might not care. If she's competent, then she will care, because the users will.

Perhaps me or my fellow developers who have to maintain a web page care... Is a table less maintainable? I think using a table is easier than using divs and css.

~~The majority of professional web developers seem to oppose you~~^{[citation needed]}. That tables are in fact less maintainable should be obvious. Using tables for layout means that changing the corporate layout will in fact mean changing every single page. This can be very expensive. On the other hand, judicious use of semantically meaningful HTML combined with CSS might confine such changes to the CSS and the pictures used.

By the way... why is using a div or a span good separation of content from layout and a table not? Getting a good layout with only divs often requires a lot of nested divs.

Deeply nested <div>s are an anti-pattern just as table layouts. Good web designers don't need many of them. On the other hand, even such deep-nested divs don't have many of the problems of table layouts. In fact, they can even contribute to a semantic structure by logically dividing the content in parts.

Readability of the code
I think it's the other way around. Most people understand html, little understand css. It's simpler.

“Most people” don't matter. Professionals matter. For professionals, table layouts create many more problems than HTML + CSS. This is like saying I shouldn't use GVim or Emacs because Notepad is simpler for most people. Or that I shouldn't use LaTeX because MS Word is simpler for most people.

It's better for SEO not to use tables

I don't know if this is true and wouldn't use this as an argument but it would be logical. Search engines search for relevant data. While tabular data could of course be relevant, it's rarely what users search for. Users search for terms used in the page title or similarly prominent positions. It would therefore be logical to exclude tabular content from filtering and thus cutting the processing time (and costs!) by a large factor.

Tables are slower.
An extra tbody element has to be inserted. This is peanuts for modern web browsers.

The extra element has got nothing to do with tables being slower. On the other hand, the layout algorithm for tables is much harder, the browser often has to wait for the whole table to load before it can begin to layout the content. Additionally, caching of the layout won't work (CSS can easily be cached). All this has been mentioned before.

Show me some benchmarks where the use of a table significantly slows down a page.

Unfortunately, I don't have any benchmark data. I would be interested in it myself because it's right that this argument lacks a certain scientific rigour.

Most web sites that need an upgrade need new content (html) as well. Scenarios where a new version of a web site only needs a new css file are not very likely.

Not at all. I've worked on several cases where changing the design was simplified by a separation of content and design. It's often still necessary to change some HTML code but the changes will always be much more confined. Additionally, design changes must on occasion be made dynamically. Consider template engines such as the one used by the WordPress blogging system. Table layouts would literally kill this system. I've worked on a similar case for a commercial software. Being able to change the design without changing the HTML code was one of the business requirements.

Another thing. Table layout makes automated parsing of websites (screen scraping) much harder. This might sound trivial because, after all, who does it? I was surprised myself. Screen scraping can help a lot if the service in question doesn't offer a WebService alternative to access its data. I'm working in bioinformatics where this is a sad reality. Modern web techniques and WebServices have not reached most developers and often, screen scraping is the only way to automate the process of getting data. No wonder that many biologists still perform such tasks manually. For thousands of data sets.

Common Mistakes for CSS-Designers to Avoid