- About the author
- Jonathan Christopher
The recently dormant topic of CSS frameworks has again spewed a bit of magma last week courtesy of No CSS Reset written by Jonathan Snook. Naturally, the topic alone is quite a conversation starter, but I’ve got to admit: I was surprised at the reaction it received. Jonathan’s piece was a very down to earth article outlining why he chooses not to use a reset stylesheet. I, on the other hand, have been using a reset stylesheet for a bit of time, and I do prefer working that way.
Now, I understand I’ve spoken quite a bit of CSS frameworks over the past year, and even though my sensational headlines have categorized my position to a greater extent than I’d hoped, I learned quite a bit from both camps during the “Great CSS Framework Debate of 2007”.
Jonathan’s post has garnered quite a few comments to the tune of developers not using reset stylesheets simply because it creates more work for them, and they want nothing to do with that. In all honesty, I fail to relate to something like that. As I reflect on all the websites I’ve worked on in the past few years, not once have I used a browser default to style an element. I always change a number of properties simply because the browser default won’t work with the design. In my case, I’m consistently writing CSS for elements with browser default styles. As I browse the Web, I don’t often examine stylesheets, but from what I can see, there aren’t many websites using browser defaults (save for
I have a hard time accepting a conscious choice to pass on a reset stylesheet simply because it causes you more work. I do (wholeheartedly) believe that a reset stylesheet may not save you any significant amount of time, but it will take some persuading to show me it truly creates more work to be done.
I prefer to work with a reset stylesheet if for nothing more than comfort in knowing every element on screen is rendering as such because I told it to. I don’t feel additional work was created for me as much as I feel the work is a bit more solid.
One point that hasn’t been risen quite yet is the topic of browser defaults in their simplest form. Who is to say that browser defaults are acceptable to begin with? I’d like to be explicit here in saying that I’m playing the part of devil’s advocate. I often take that stance with issues to put myself in some new shoes.
I completely understand why browser defaults are put in place, it would be silly to try to debate that point, but my question to knowledgeable developers is this: why do you prefer to work with browser default styles?
We’ve all come to accept that pixel-perfection is not worth the headache, but using browser defaults will indeed increase the variance of your design. I can agree that it’s not a big deal, I’ve just found it to be a personal preference of mine to avoid. I’m completely fine with slight differences in rendering when comparing browser to browser, we’re not designing print brochures after all. I do make an effort, though, to keep things to a minimum.
As a follow-up, I’m curious to hear how many developers found it troublesome working with browser defaults when just learning CSS? I’m self-taught in quite a bit when it comes to what I know about Web development, and I’m not too embarrassed to admit I was honestly confused when it came to default styles on heading elements in my early days of working with CSS.
In my honest, personal opinion, I don’t feel that browser defaults truly belong. That is not to say I feel they’re inapplicable. Without browser defaults, Web design and development be in a different boat altogether. It’s just that after looking at things from a more distant standpoint, browser defaults seem partially counterintuitive to me.
The idea behind a framework is to save yourself time and repetition, but in my experience I rarely find myself repeating any significant amount of CSS project to project. That’s one of the biggest reasons I have chosen not to use a public-facing CSS framework such as Blueprint or YUI. There is a significant population who does make use of the frameworks and I think it’s great. For them.
While a framework can technically be defined as something which can be consistently reused and applied to any project while working for your benefit, a reset stylesheet, to me, is more unique than that. I view a reset stylesheet as something to level the (rocky) playing field when it comes to writing CSS. As I write that, I realize that’s exactly what Blueprint (or any other CSS framework) is trying to do. I think a reset stylesheet changes things in a different way, however. Instead of working to help you out with browser quirks and retain consistency, a reset stylesheet is more of a big eraser, providing a ‘clean slate’ if you will.
A reset stylesheet does inherit an important benefit of a framework: instant implementation. A reset stylesheet is as easily implemented as keeping a local copy on your hard drive, copying it to your CSS directory, and including it in your document(s).
At the end of the day, I’m not sure that I can refer to a reset stylesheet as a framework by itself, but instead consider it an optional piece of one. I’m sure many will disagree, but a reset stylesheet to me is more a piece you work on as opposed to work with.
As with the original CSS framework debate, it comes down to personal preference and what works for you in your workflow. It’s been said before and I’m going to say it again: I’m glad such a large number of designers and developers are ready (and more than willing) to have this conversation. On top of that, everyone has personal experience to back it up.
Because this isn’t a field of straightforward answers and universal solutions. We are often faced with problems that have multiple solutions, none of them perfect. To understand what makes each solution imperfect and to know which of them is the best choice in the situation—that’s knowing your craft. That’s being a craftsman/craftswoman. It’s a never-ending process that is all the more critical precisely because it is never-ending.
So it’s no surprise that we, as a community, keep building and sharing solutions to problems we come across. Discussions about the merits of those solutions in various situations are also no surprise. Indeed, they’re exactly the opposite: the surest and, to me, most hopeful sign that web design or development continues to mature as a profession, a discipline, and a craft. It’s evidence that we continue to challenge ourselves and each other to advance our skills, to keep learning better and better how better to do what we love so much.
I wouldn’t have it any other way.
The rest of Eric’s entire response is extremely well written, and definitely worth the read.
I do find it a bit troubling, however, that with a number of comments left in response to recent articles written on the subject of reset CSS, zealotry continues to pop up. Everyone has a reason, good or bad, for how they do things. It’s important to have civilized conversation on the subject as opposed to narcissistic comments which don’t help anybody.