Don’t start with a reset.css

Earlier this year, Jonathan Snook wrote an article on why he doesn’t use a reset.css in which he referred to Eric Meyer’s reset, a short time later, Eric Meyer responded with an article of his own. Unlike many discussions on the web, it wasn’t a mudslinging match, but a sincere discussion of the tools available to web developers.

My initial thoughts were that a reset style sheet, combined with a base style sheet, was a helpful place to start any web project as it reduces the incidence of unexpected results. I thought it was important for the developer to have her own reset and base styles; blindly adopting someone else’s reset and base style sheets will just lead to a different set of surprises.

While these discussions were going on, I was in the process of developing my own base style sheets, running them against YUI’s XHTML test suite; shortly afterwards I began to regret the decisions I’d made.

I concluded that the best place to start was with my own base XHTML document, something I can start a project with and remove anything that’s not needed for the particular project.

Viewing the source of my base XHTML you’ll see an overly complicated document that will never be used in its entirety on a single project.

<div id="content-body">
  <div id="content-a">
  </div>
  <!-- //#content-a -->

  <div id="content-b">
  </div>
  <!-- //#content-b -->
</div>
<!-- //#content-body -->

In a project with a single column of content, there is no point in dividing the content into content-a and content-b; that’s a deliberate redundancy, I’d much rather highlight a block of code and hit delete than re-write type the code every time I need it. The same process applies for sidebar-a and -b.

None of this is to say that base style sheets are bad, they’re still very useful tools, just that it is important to begin with something to run your styles against.