1. stop unnecessary floating

The code above is something you find quite often. A simple block level element that is floated with a width of 100% to make it span the complete width of its parent. In most cases, removing the float and width will result in exactly the same rendering, only with more flexible use of margins and paddings. So what gives?

What usually happens is people fail to understand the workings of collapsing margins. Floating the element triggers a more understandable use case where margins are not collapsing with margins of surrounding elements. This is okay until you need to add paddings, margins or extra positioning rules. Furthermore, this code isn't very browser-proof and you'll often end up with nasty ie6 troubles.

There are better ways to work with (or around) collapsing margins and besides, floats are never a good way to fix things. Using floats to fake a block level element is completely useless and will definitely result in trouble later on. So no more.

2. margins and paddings

Margins and paddings should never be used together to create one single space. Both properties can be placed on leafs (an html element with no children) in certain circumstances, but apart from this use case it's better to stick with either one of the two to define all spacing around an element.

Usually statements like these come forth of laziness or bad planning. They are the result of last minute changes or unfocused code weaving. All understandable excuses, but if you claim to have a professional attitude you just can't leave them in your code.

I don't really care whether you prefer, paddings or margins, but combining them to create one single space is never a good idea. So no more.

3. width abuse

Use widths only when really necessary. People tend to go all math on their css while css is (somewhat) equipped to do most of the work for you. In the example above, the width declaration on the .child is completely unnecessary. It would be much better to simply add a right margin on the .child element (unless you'd really want the child to be 49em wide independent of the width of its parent). Using paddings or margins instead will ensure decent rendering even when the parent would change widths.

I've had several projects where the goal was to widen a site. It's true bliss if you can do this by adapting just a couple of values in the css without worrying to much about browser inconsistencies. A project like that turns into hell on earth when each component has a specific width defined, especially when these components just take up the available width anyway. It really makes the difference between an hour work or two days of hard labor.

For positioning an element relative to its parent, use margins or paddings. Only use widths when an element should explicitly have a fixed dimension (not saying it should always be in px though, it could be ems just as well). Widths are for reserving space, not for spacing. So no more.

4. mending and fixing

There aren't too many things the web design community as a whole agrees on, but when it comes to ie6 most (if not all) people agree that it is an outdated, hard to code for piece of software junk. And while I won't contest that statement, it must be said that most of ie6's problems can be fixed quite consistently. Whether you use inline hacks or conditional comments doesn't even matter, how you actually go about fixing these issues is more important.

Many of ie6's bugs exist of (little) misplacements of elements. Most people try to fix these issues by re-aligning them specifically for ie6. For example, if an extra 6px space is added to the left you can counter it by defining a negative margin of the same size. This is crap coding though, as you're only just mending the problem rather than really fixing it. ie6 might be a true bitch, but most of its bugs can be countered as to make it behave like other browsers.

This is pretty important as these fixes will continue to work when the original css is adapted. Rather than defining a negative margin, make sure ie6 renders the item as it should, so future adaptations won't need extra fixing. Making ie6 behave is not easy, but far from impossible. So no more.

5. reset without rereset

I have nothing against reset css, be it coming from a standard script or coming from custom coding. As long as you make sure to set the general styles back, I'm fine with it. I do get furious when encountering a css where simple text paragraphs don't even have a margin (or padding) defined on them. This is simply not done and extremely sloppy coding.

So use these reset css styles as much as you like, just make sure to set the basic styles again. Make sure your paragraphs look like paragraphs and lists feature some kind of list element indications. These quick resets eliminate styles that are important for displaying general data, not setting them back to a good standard is pure amateurism.

conclusion

Basic as these five remarks might be, you'd be surprised how many front-end developers still make mistakes like these. There are many reasons that seem to fuel this state of affairs, like lack of proper schooling or a good fall-back place for css best practices to go to when starting out with css. Most people learn from scattered blogs and snippets found in articles, which is probably not the best way to get to the bottom of what we do. This makes finding a good solution a pretty tough task though.

The list above is more than just my top 5 of commonly seen css ugliness, it's hopefully a wake-up call to whoever feels the passion and energy to create some kind of starter's platform for css best practices. Through all the bling and sex of css3 these issues are once again eclipsed, but they might be even more relevant than two years ago with a whole new group of people starting to learn the tricks and trades of html and css.

So no more, it's time to take css to its next level. And no, I'm not talking modular css or advanced animation, just a good set of best practices and a well considered starters platform for people to get started.