No CSS Reset
When asked recently about using a CSS reset stylesheet, I readily admitted that I don't use them. I don't use them for my blog or for any project that I work on. Admitting such can raise an eyebrow or two. Reset stylesheets are definitely becoming commonplace — as you'd expect with companies like Yahoo and industry leaders like Eric Meyer actively using them.
So, why haven't I jumped on board?
What is a CSS Reset?
In case you've never heard of such a thing, a CSS Reset is designed to set a number of element styles to a specific baseline that creates consistency across various browsers.
In the beginning
When the idea of a reset style was first introduced, it was very basic. It reset the margin and padding for all elements. The problem with that was it caused havoc with elements that didn't want their margins or padding reset (namely, form elements).
* { margin:0; padding:0; }
From there, people worked on adding to and fine-tuning the reset stylesheet to be more flexible and to reset more styles. The Meyer reset is probably the finest culmination of this effort.
Eric Meyer's Reset
Eric Meyer's reset took the concept of resetting margin and padding and took it to a whole new level, stripping styles from a number of elements, forcing you to think about what you wanted and add them back in. List items would no longer have bullets, headings would no longer be bolded, and most elements would be stripped of their margin and padding, along with some other changes.
Working with Nothing
The problem I've had with these resets is that I then find myself declaring much more than I ever needed to just to get browsers back to rendering things the way I want. As it turns out, I'm perfectly happy with how a number of elements render by default. I like lists to have bullets and strong elements to have bolded text.
And I'm okay if the various browsers show things slightly differently.
I'm okay if one browser displays an H1 a few pixels larger or smaller than other browsers. If one browser defaults to circle bullets and another to squares, that's usually not a problem. If it is, then I create a style that addresses that specific issue. I don't reset it back to zero and then set it again to what I really want.
One of the principles I took away from the Web Standards community was the concept that pixel perfect precision across the various rendering engines was impractical and a remnant of the table-based layouts of yesteryear. With CSS and progressive enhancement, it was okay that things might look a little different from one browser to the next because of variations in what they supported.
Building up
With that said, the idea of developing a base CSS file that defines some common styles that I often want from project to project — like turning off margin and padding for form elements — is a good idea.
We're seeing various CSS frameworks crop up such as Blueprint, YUI and 960.gs. Each breaking the system down only to build it back up again. Each starts with a reset, then adds on typography and a grid system.
Each of those still seem like more than I need, even though none are that large in size. Blueprint is the heaviest at around 13KB uncompressed but also includes lots of extras like styles for error messages and a print stylesheet.
Less is more
One of these days I'll put together my own base CSS or maybe I won't. To date, I haven't felt myself being overly repetitive in the styles that I set; and I haven't thought to myself, "oh, the hours I'd save myself if only I had a reset stylesheet."
So, while I have nothing against CSS reset stylesheets, I simply don't use them personally and I think that's okay.
Conversation
Im still getting to grips with that! However, i guess it also depends on one's comfort level of how varied a browser render you can tolerate. In my case, its still close to very low.
I completely agree. Every time I start a project and attempt to use a pre-made reset (be it Meyers, BP, etc) it always seem to cause more work in the end. I end up canceling out or undoing half the elements from the reset (headers!).
I think have *some* sort of ground work to start off of be efficient, but unless the project specifically needs it- I just haven't found it beneficial.
I periodically go back and try using different resets- but I always end up at the same conclusion. Maybe one day my mind will change and my design habits will incorporate a reset file.
Great write up btw. It's good to know there are still some other designers left out there that don't use resets.
Cheers!
Resets can certainly be a pain - if you're not sure exactly what it is doing. Once you know the things that it will cancel out (and what it won't) it's not too difficult to specify the styles that YOU want (opposed to the browser).
Certainly there is a lot of negativity in pixel pushing and it can be many a web dev's nightmare but unfortunately from my experiences people really do want things to look the same across platform/browser and CSS resets can/will/have help with this.
I've certainly been frustrated with them in the past but now rather like them :>
The other problem with using reset styles is that they add unneccessary rules to every element on the page which presumably adds processing/rendering overhead.
I agree with your points, however I still use the reset css. In fact I use quite a heavy reset by default, but instead of adding bits back in (such as making strong text bold again) I just remove those things from the reset. I find this works for me.
I've also looked at a few of the prebuilt css frameworks and can't say I'd use any, of them all I think the popular Blueprint framework is the worst. Take time to develop your own, not only will it work better but it will help you develop your own skills further.
I use a very basic reset, literally just for margins and relative font sizes. I've never really seen the necessity to create a fully clean slate. As long as it renders roughly the same in each browser it's fine. If you're constantly adding in CSS that was already there as a default then you're wasting your time. The browser defaults are all very similar anyway.
It would seem to me that a full reset is merely an attempt to be 'overly semantic' (if there is such a thing) with your code.
Loving the blog. Consistently good and useful content.
Whole-heartedly agree. The last thing I want to do is start from scratch. I agree on building up a base - such as with font sizing - but brining all elements back to zero seems overkill. Add in http requests, page weight, maintainability, and I think the cons out weigh the pros. Migrate the code to a new developer, and you can be in even deeper.
Honest post. Nice work.
It's an interesting discussion. While I do agree it's sometimes a matter of taking out just to put back in, there are other times when it is very important to be able to give the end user a good user experience.
While most people are aware that pixel-perfect designs are, more or less, impossible to achieve (it's a living medium, not a poster, folks), there are times where you want to be as accurate as possible when it comes to creating a result which is as consistent as possible across web browsers and platforms.
I generally use a small reset part in the main stylesheet (not tucked away in a hidden file), and I'm fairly picky about what I reset.
I have a number of gripes with reset stylesheets:
In Meyers reset styles outlines are removed from focused links, with the rational that you have to put them back in as you want. This is very bad in my opinion - the inverted dotted outline is distinctive and understood as a usability convention - should Never be messed with or altered from the browser default.
Also removing bold from headings, italic styling from em elements etc. Is overkill. every browser that I've ever seen has the default styles set intuitively in the obvious cases - and they're there to help the authoring process - I certainly appreciate them.
没有使用过* { margin:0; padding:0; }è¿™æ ·çš„å†™æ³•ï¼Œä½†æ˜¯ç»å¸¸ä½¿ç”¨div{ margin:0; padding:0; }
Yay! About time somebody (at least somebody with a blog that gets read) mentions the non-essentiality of reset stylesheets. I don't use them and find that when I have, I've spent most of my time re-emboldening header elements and such like. After stripping away the margins and padding I'm then quite happy with how most browsers render my site. Some sites of course may require a little more 'stripping' than others - but once these areas have been identified, then its a two-minute job to set a targeted reset for them.
Good on ya Snook, for writing about this!
@justin
The link outline is only removed from Firefox iiirc, this outline can look pretty nasty at times and can even interfere with the page rendering in some instances.
Instead use the :focus pseudo class to apply the same styling as :hover, that way there are no issues tabbing through page links and the user still receives feedback.
As it turns out, I'm perfectly happy with how a number of elements render by default. I like lists to have bullets and strong elements to have bolded text.
This is fine, and perfectly valid, but seems to reject the reset sheets from the approach that they are Things Not Edited, which Eric explicitly addresses on the page for his: "It should be tweaked, edited, extended, and otherwise tuned to match your specific reset baseline." If you instead prefer your B tags bolded and ULs bulleted as a starting point, it's trivial to produce your own "fork" of the Meyer reset to make it so. Rather than a final product, I'd just think of them as someone having already done some of the work toward that personal base sheet you're setting aside for the future. With Eric's at least, there's a pretty strict adherence to a single goal, eg. the reset.
The problem I have with some of these and the frameworks is that they have a tendency to go a few steps too far. Blueprint, for example, defaults to centering your layout, which I don't think it has any business deciding for you. And I'm also questioning of so many colors being specified in the typography module. I don't use that portion at all, but conceptually I'd prefer that it stick to metrics and leave color up to the users rather than require them to repeatedly contradict the Blueprint author's choices.
I, in general, like the idea of a reset spread sheet; it’s the search for the mythical ‘the’ reset style sheet that perplexes me.
Each developer has their own style of coding, put three developers in a room with a design, and you’ll receive three different products; each product will have its advantages and disadvantages.
I’m in the early stages of setting up some base css for myself, I’ll start with Eric Meyer’s reset.css and remove a few things that – I think – take the reset too far to be practical; this is, as has been said above, what EM intended to be done all along.
I totally agree that, in most cases, a CSS reset can be overkill. Browsers are fairly consistent in default rendering these days: one or two extra CSS declarations here and there can solve the majority of issues.
A reset is possibly useful if you're new to CSS or aren't testing in many browsers and don't want to many styling surprises.
Great blog BTW!
Great article - love questioning the 'norm'
I agree with the fact that the reset stylesheet issue has got a little out of hand. Yes, some elements - such as lists - need their margins and padding standardised to reduce headaches, but I like the idea that headings and form elements should be allowed to display as originally intended across different browsers - the users of those browsers are used to the way these elements look so why confuse them?
Vive la difference!
Thats the only one I use, and thats just out of habit more than anything. I would like to leave it out, but there are a few cross-browser nuances that still get on my nerves involving these two factors.
I say this to my designer colleague all the time :) In my eyes, ignore the few pixels difference in width, just be thankful your floats aren't jumping around the page.
I don't use CSS resets either, mainly because I believe it's excessive since I'm probably not gonna use everything that's defined in them, plus the fact that I'll probably be rewriting mostpart of the rules anyway.
Purely ancedotal, but using a reset (edited, of course, and usually Yahoo! or BP) has drastically reduced the amount of time I spend on cross-browser issues. I often don't even need IE-only stylesheets. A reset smooths out those pixel differences, which are frequently the reason for a broken layout.
This is the only baseline style that I start projects with. Though I bookmarked a slew of reset stylesheets with the intention of comparing them and pulling some useful declarations.
It's easy to say that you don't mind certain elements looking different in different browsers when you have full creative control. But when working in a team environment it's a bit harder, so you give as much as you can (and as much as makes sense) before drawing the line and trying to negotiate a compromise. Especially since a lot of the graphics types are used to the "precision" the table based designs of yesteryear afforded them.
I agree, I have never understood the popularity of reset style sheets. But, after reading some of the above comments I agree that a custom reset wouldn't be such a bad thing if you took the specific project into consideration and only added resets for the elements you were using... But then, if it's project based targeting only specific elements wouldn't it just be called a style sheet?
I am actively using Meyer's reset sheet and I find myself comfy with it. No reason not to use it in my opinion.
I work with designers used to the print medium. While I've gotten them to make a few concessions, pixel perfect is what they know and resets just make things easier. They're still frustrated text wraps differently in different browsers and try to get me to use line breaks to fix it.
I find myself repeating CSS on just about every project I do. I use most of Eric's reset
on my starter css/html template. I find that this template can almost always meet the needs of any website design. Occasionally I'll need to remove a few elements or add few. Another nice thing to add to your default style sheet is css diagnostics which will alert you of any blemishes in your code.
After it's all said and done, I still like reseting everything. There are just too many inconsistencies between all the browsers.
I'm going to have to respectfully and wholeheartedly disagree.
One of the greatest hurdles for me when I first started learning CSS was trying to figure out what mystery properties were being applied in order to try to offset them. So much of my time was spent zeroing out things haphazardly because I wasn't sure where all the mystery margin or mystery padding was coming from. This becomes even more frustrating when you learn that different browsers come with slightly different "defaults".
With a reset stylesheet, I no longer have to have all of those different defaults floating around in my head. I start with a fresh slate and specify just exactly how I want it to look.
Do I think some go too far? Sure—why unbold the strong element? But largely, I think it helps people better wrangle CSS, so I recommend it to all beginners.
I just recently used a reset for the first time and it caused so many frustrations I just ended up not using it. I'm ok with different browsers displaying things a bit differently. But explaining that to a business person who is dead set on the website looking 100% like the mock up is difficult. :)
I've been using the universal reset for awhile, and finally got tired of not being able to style inputs. So I took Meyer's reset and slimmed it down. I left in a lot of the defaults such as sizes, spacing, and bullet points. I do end up writing over what is left, but my reset helps a lot in simple avoiding confusion later in development. It keeps me from wondering, "Why is that element way over there? Oh, it's a browser default..."
I'm a bit surprised by all this anti-reset sentiment.
Since I've used a reset the amount of browser-targeting hacks in my CSS has dropped by 70%. Not to mention the high level of control I have with font-sizing.
The complaint of 're-enabling' all seems pretty insignificant. Sure it sucks and it's not often you need to declare
b,strong{font-weight:bold;}
. But, you really only need to build your baseline stylesheet once, and then you can use it on all subsequent projects.So to me, getting that solid consistent cross-browser foundation is absolutely worth the time.
Some great comments here. I didn't realize this was all that controversial an idea. I have to say though, I'm a little confused by all the comments saying "I always have to add/remove _____ from Eric's reset.css" Why not just add/remove them once from the reset.css itself instead of undoing his stylesheet in yours?
The strong/em thing got me too at first. I think I forgot he removed styles on those too so I just went and put them back. I change a few other things too, adding a hr style for a simple line and adding nathan smith's div.clear, and my .hide-for-print class. Things like that which don't have an immediate effect on the design themselves alone, but things which I am typing (or copy/pasting from my other stylesheets), are all things I've added to Eric's.
I also have a base.css which gives me fonts and margins on headings and paragraphs I use a lot, and even some comment/calendar styles for wordpress but I'm finding myself undoing some of those a lot so I'm thinking of just making a "blog" reset, "corporate" reset, etc. for those different uses.
And you're right, I haven't saved a ton of time, but I like to think I'm preventing carpal tunnel. :)
Well obviously it's just a matter of personal preference. My site doesn't use the Meyer reset.css, but I've been using it lately on new projects. I'm still trying to adjust to not having anything set up front, and I admit, I don't always like it.
Another thing I'll mention is that I got used to coding around browser defaults, and now sometimes when something doesn't work I'll end up spending two hours trying to fix it, only to realize that it wasn't really broken. It was something that was reset in Meyer's reset.css.
And yeah, the em/strong thing threw me for a loop too...
I'm with you bro. Never used it, don't care to.
Jonathan I too didn't use resets until recently. I worked for a large marketing firm and having the website render exactly how the comp (design) looked was huge. I would either hear from account service stating the client approved a certain look or from an art director claiming the padding/margin was off by a pixel from their comp. I truly now could not live with my css reset, and I'm constantly changing it as I see fit. BTW anyone who would like to see a copy of my css reset is more than welcome to it.
I completely agree. I have my own "reset" that just removes the margin and padding on block level elements. But yes, I am perfectly happy with a lot of the other browser defaults are. The goal for me now is to educate clients that things will not look 100% identical in all browsers. Do they think that their customers will bring up 2 different browsers and compare the site? No way.
I'm freaking shocked.
I mean, yes, it's all a matter of preference. Do what you like. Whatever.
But I've been on the other side of the reset.css methods/ideas and I don't want to go back. Hell no. We're working with layouts that, I would imagine, you want to be *consistent* ... isn't that right? Being all willy-nilly about "oh I don't care if it's a few pixels off" - will eventually bite you in the ass down the line when a client throws down on some weird inconsistency because their lame "enterprise" throws you a curveball that isn't accounted for, therefore forcing you to hunt down the rabbit hole for all selectors that might touch those elements ... fixing margins, then having to fix more, ad nauseum.
Madness. Start off with a consistent baseline, throw out the incongruous variables that can drive you NUTS in the future, and then have a beer. Or something.
I've found myself use the reset and typography components from BluePrint more and more. Its modular structure pretty much allows me to load or unload the components I do/don't want, which is great. It has saved a lot of time for me since I used to end up writing pretty much the same basic CSS for every project (vertical rhythm etc). I would never dream of using the print stylesheet or their grid system (non-semantic class names that would leave me really puzzled), but whatever's up your alley is fine as long as you get the task done faster :)
I think this is a very good set of points you are making here. I have been told off by some 'standardistas' for not using a reset, but 8/10 projects worked fine for me without using them. No you might not get exact pixel perfection, but most site designs can handle that quite nicely and do not require surgical precision in terms of layout. I am so glad you have written this, as it gives me some good counter-arguments for people like the ones I just mentioned. Cheers!
I was going to respond here, but ended up doing so over at meyerweb instead. (I got wordy. Anyone surprised? Didn't think so.)
I've so far been resetting what I need as I need it; it seems that a mass reset wastes more time than it saves me in correcting the browser difference problems.
For some reason, people seem to read blog posts that say, "this is how I do things, and it works for me," and take them as, "So-and-so says do it this way and if you don't, you're wrong."
The reality is that we all do things our own way, and that's awesome. If resets and frameworks don't work for you, but they do for me, that's awesome. It doesn't need to be an argument for someone to "win." Try things out, find a workflow that works for you, and more the eff on.
I have always thought that reset style sheets were an idea for beginners.
What would be a better idea for beginners would be to learn the attributes that come with certain XHTML elements and use them where they needed and change them where they aren't needed.
But when the self styled guru of CSS is arguing against you it is hard to get anyone to buy into what you are saying.
I also have lots of other crazy ideas like:
Reset everything approach, I have felt, is for those who have redesigned every single element for their site. Which is not usually the case on most sites, so definitely a technique that should not be a standard way of starting a layout, but unfortunately it has become one.
I was initially sceptical of the reset, but once I used it I fell in love with it. It just allows for so much more control to fine tune everything without having to worry about what it would do in X or Y.
Thanks for putting this conversation out here, Jon. I too am not a fan of reset stylesheets. I've given them a try, and I often have to work with sites that start out with a reset, but to me it just doesn't matter. Sometimes I start out with
* {margin:0; padding:0}
, but I usually end up adding margin and/or padding to most layout-specific elements anyway, so it's not a big deal.While I absolutely understand your reasoning (after all, you are defining way less CSS without a reset), and seeing the comments have about the same sentiment, I think you (and most others) would be on the complete other fence when it comes to javascript or HTML.
Would you want implied behaviour, that's about half of what the browsers thinks it should have, and half of what you define? And have it differ between browsers ever-so-slightly? I think not.
This is exactly the thing a CSS reset does for CSS: It takes away the implied CSS styles, the styles you can not count on to actually be there.
Without a CSS reset, you built on top of them without being sure that they're actually defined, let alone defined as you want them to. That seems rather illogical, doesn't it? Sure it works now, but what if the standard CSS of a new browser version differs just slightly enough as to breaking your layout? Then you'd have to go back and rectify it. With a CSS reset there would not have been a problem.
Having said that, just do what you please. If not using a CSS reset works for you, then that's awesome and don't let anyone but yourself change that :)
I do think Kilian makes an interesting side point. There does some to be a sort of weird disconnect that I've noticed in that many of the same people who are all for Javascript libraries, microformats, and other co-reuse and standardization seem to hate the idea when its applied to CSS. I'm not sure why that is, but I think it's interesting.
Amen.
Snook, I completely agree with you. I have never been able to use the CSS Reset sheets. I usually would go crazy because it reset something and it would take me a while to remember that it was being reset to go back and override it for small things.
So, I reset things like the margins and paddings and thats about it. I guess you could say "That's how I roll"
<span onmouseover="javascript:alert('test')">test</span>
eheh sorry, I was playing with the live preview. pretty cool btw
Seems that people whom do a lot of designs, sites, skins, whatever from sratch would quickly see the value in these CSS frameworks. I know I do!
I've used both the YUI CSS framework and the Blueprint CSS framework. I have to say both are pretty nice, thought he YUI one doesn't validate which bugs me. I think the Blueprint framework is awesome, has tons of potential and gives you the ability to programmably write mark-up. « I know people are going to hate that statement, but in the world of web applications not web pages, programmable XHTML output is very beneficial.
As for the comment about Blueprint adding to your page weight; it's extremely small when compressed and severed via gzip (anyone have numbers on this?).
thanks for this writeup. very useful.
I completely agree.
I did recently try using Eric Meyer's reset on my blog - thought I should give it another go as it had been a while since trying resetting - but I actually found myself just taking elements out of the reset to return them to their defaults. It was just more than I needed.
Instead I just tend to have a semi reset rule which removes margins and padding for the elements that I find need it as I go along. Much lighter!
I havent used reset styles either because I was thinking the same thing, more work to get back what you want. But I wouldnt rule out not using them for a giant site or for experimenting.
I agree in part.
For your average blog, or mid-sized portfolio website or CMS, I don't believe a CSS reset is really needed, or even very useful. After all applying a lot of rules to * is fairly render heavy.
But, if you have ever worked on a large scale web project, something with a heavy code base and a development team, the qualities of a hard-reset start to come through. I've been working the last year for a company who's product runs into hundreds of thousands of LOCs, and over 10,000 lines of CSS. It's not bloated or heavy, it's just a very big website. We built our own reset from scratch which in turn rebuilds every element in a very specific fashion, most of them fairly differently to browser default, with exact and purposeful spacing and rules. It took a lot of tweaking at the start and takes maybe 300 LOCs. When this is combined with a custom element layout framework the problems it solves when using many many elements over and over in different scenarios is priceless.
Though the key point there is that everything is hand written for our needs, out-the-box resets or frameworks are one of the worst ideas ever, because as you say, the majority of the code is redundant.
As I’m not much of a designer, I’ll be using a modified version of Eric’s reset styles on my next few personal projects, to force myself to consider what everything should look like. I’ve found it a helpful way to get into the nitty-gritty aspects of design.
You put into words exactly how I feel about pixel perfect precision. Thank you for that. I haven't been following the "css reset" movement, but I've been working with a client who is using screen shots to check my css layouts.
It's hard working with someone like that when *my* main concern is that the site looks reasonably ok in most of the major browsers.
Well then you might want to check your javascript. It's throwing an error:
@Tom: fixed. thanks. :)
Perhaps you missed this, but Eric says "this is a starting point, not a self-contained black box of no-touchiness."
Take all of those 'reset' rules, and, for every selector, figure out the margins, padding, etc. you prefer. That way you have your own "framework" to use over and over.
I am working on such a framework for myself now. I won't need to use the reset after I'm done, because every HTML element selector will have the initial properties I prefer.
This is really interesting Johnathan. I have been using Eric Meyer's reset.css file on some of my projects for a while now, however I totally agree with you when it comes to rendering lists with bullets rather than resetting it back to no bullets.
Although I think there is a place for reset.css files to address padding and margin issues across browsers, I feel it is slightly bloated... at least for my needs.
My 2 cents:
1) Resets are about reaching the global community with a common design rendering. Which doesn't matter for you if you only code for a niche of viewers.
2) If I hear you right, your mutated viewers are not important enough to get your design to layout for everyone.
STUMBLED!
First I ever heard of this, does this effect speed?
VOTED for you at:
http://www.newsdots.com/design/no-css-reset-snook-ca/
I agree with the use of the correct tools as needed.
As James stated in Eric's response:
and from a post here which sums my own situation clearly:
Finally, as it seems everything has already been said for me, thank you to Lori for one last citation which struck me as a beautiful way to sum it all up:
So, heartfelt thanks to everyone in the field, for without our tools we would have nothing!
I have one that I use, but I just recently started using it. It does save me a little time, however, as I develop more sites I'm noticing a pattern in how I use styles in relation to my markup. Because of that, I'm thinking about reworking my reset style sheet. I've noticted on elements like unordered list, the only time I really want bullets is in an article/post of some sort... in most other cases it's being used in navigation or something else where I'm not going to have bullets, but rather my own set of styles. So if in most cases I don't want bullets, it'll be easier on me to go ahead and reset an unordered list rather then basically reseting every separate unordered list on the page as I need it.
Not only that, but I like the idea of it dealing with different browser issues ahead of time, so I don't have to worry about them nearly as much when writing my styles.
Some styles, like the p tag, I reset and then set again in my reset style sheet. This way it will have the spacing between paragraphs without me having to specifiy that everywhere I use a paragraph tag. All I have to do is include my reset style sheet. Over all I think it's saved me a considerable amount of time.
i think the reset css is only half of the equation. re-enabling as you mention is a lot of work. this is why i use w3c's sample of what html4's css should be: http://www.w3.org/TR/REC-CSS2/sample.html. this way, i know that i have the same base across multiple browsers. but i agree, it's not worth it to worry over a few pixel. i just want a certain level of consistancy across browsers.
I agree Jonathan. I once said on CSS discuss that someones code was suffering from the universal reset bug. I have never used the universal reset and I never will.
@DameryWorld:
That's hardly the case at all and I think you missed the point. The point is that a slight variation between browsers does not take away from the reader's experience and I don't feel the need to strip down all styles only to add them back in. If I need to address something specific, I will create a style addressing that issue.
The most constructive part of using a reset (for me, anyway) is to have a consistent base from which to start. I haven't found a reset that I consider perfect either, but I have one that I use for every project.
Pixel-perfect replication across the gamut of browsers is a silly goal, but it is still the goal for a lot of clients, and they get angry if you don't do it that way. Having a standard reset helps to get closer to that goal. Anything aside from what can be explained away by font rendering issues still frustrates clients.
Until the mindset of clients changes ('the web can do everything that print can do' is part of that mindset), web designers will be frustrated by 'pixel-perfect replication.'
I've done my fair share of picking at CSS Frameworks and I totally agree with you that "less is more." But being a CSS developer myself, and working with CSS everyday, I created my own CSS Framework that has a reset and base. Since I created it; I understand how to use it and implement it on all my projects and build off that. I can honestly say it has saved me hours of development. It adds and extra 8kb on to the load (uncompressed), but that doesn't bother me at all.
Manual trackback: Why “Reset†Style Sheets Are Bad.
actually i used the reset CSS of YUI it it is working good for me but i had to change some styles defined in the reset.css...
However our most challenge is to make sure the website we do look the same on all browsers and all platforms for me everything looks fine in all browsers on PC.
but the Pain when i check the website on MAC especially Firefox on MAC.
i still didn't find anything for firefox on mac such as hacks or fixes but i wonder what i should do!
do you think it's better to start the design on MAC and after that check it on all the browsers on Windows?
Thanks alot,
Mohammed Alaa
In my honest opinion it's the only way to have a nearly pixel perfection website compatible with most of the main web browsers. The absolute perfection is impossible to have, but without css reset, especially building medium-big complex websites, trust me, it uses a lot more code to reset some properties selector by selector.
But I like what you are saying about web standards, I find it right, it's more important to use less code, the right code, semantically and having a non perfect website, rather than having a 98% perfect website but with so bad messy code.... this is the web, not graphic design for the print!
I've seen several people mention that they use the star reset:
which I view as bad practice (it has compatibility issues) and really not all that helpful. If you're going to have to rebuild all of the styles in your site, why not just set them in your reset file?
I think the goal is to turn it into a Base CSS, rather than a Reset CSS. Let it do the basic legwork for you, rather than starting from the ground up for every project. It's worked for me in a variety of situations, from multi-developer teams complete with CSS n00bs, up to large-scale websites with plenty of bad, user-edited HTML.
If anyone wants to use it, I've published it out on my website: http://labs.zorked.com/lib/base.html. I'd appreciate comments and suggestions. More info here
This is EXACTLY what I was looking for. Thanks for the writeup.
Maybe I'm a little innocent here, but I _do_ think pixel-perfect layouts are something we should still try to achieve; there are so many possibilities that can be opened design wise and interaction wise that still can't be accomplished with fluid layouts.
That aside, I think you're bang on when it comes to CSS resets taking too much out. Early on I went through Eric Meyer's CSS Reset and stripped out everything I didn't want explicitly set; the half hour it took me to do so has paid off in spades. Maybe that's the best compromise?
That is one of the most ridiculous things I have ever read.
Although I feel that browsers resets are a case-to-case basis, I would find no reason at all to allow site design discrepancies across browsers. The apple website looks the same on every browser. Are we now justifying that "it's ok to be somewhat mediocre and not strive for the same quality most professional websites display"?
That, IMO, is utter rubbish.
Let me echo Croft's comment to start with: use what works for you and your situation/workflow. Jon certainly isn't saying anything different from that, just explaining how he prefers to do things.
Now, Jon/Steve/Bryan and I have recently discussed the reset topic, and it's interesting to see the pros/cons coming out here in the comments — as a pixel-anal designer (the same goes for Bryan), I love stripping the default styles down to a common base set, and building up from there. True, font rendering can't always be consistent (yet), but just about everything else can, and if every pixel counts for you, resets are a great way to reduce some headaches, and though I only recently started using them, I'm already in love.
To address XLCowBoy's comment above: it isn't "rubbish" to say that minor variances between browsers/platforms are acceptable - if they don't impact the visitor's experience, such discrepancies are part of designing for the web (#1 varience for me: I specify Helvetica before Arial, so many sites I build will have a different typeface on OS X & Windows. Is that a discrepancy? Of course; a problem? Not likely.).
And Jon's not saying you shouldn't reset styles that don't work for your needs, so if your goal is pixel perfection, go for it (with or without a specific "reset" stylesheet).
So, why should i white smth like this:
…for all list-based menus and other elements builded on semantic markup, instead of using simple lines in reset.css:
If you mean lists, def.listst, strongs and other semantic elements as only content markup — you maybe right, but i'm using this elements in various situations, where i don't need browser defaults.
So, i'm using customized version of reset.css and don't wasting my time for the obvious properties.
But thanks for starting this discussion.
Guess what? Apple's website does NOT look the same in every browser (pardon the oversized animated GIF to prove my point). Maybe Apple is mediocre. In fact, they're most consistent when they use images for text (especially the home page). Even funnier? They DO use a global reset... (the store seems to use *{} and not a variation on Meyer's that the home page uses).
So, yes, I still don't think a global reset solves the pixel perfect precision issue and will continue to create styles that target my design. No need to demolish the building when all I need to do is rearrange the office.
That's actually nice to see that even Apple isn't pixel-perfect.
I do use a slimmed down version of Eric Meyer's reset mashed up with Andy Clarke's from Transcending CSS, and removed elements that I have never (in 4 or 5 years) used like
var
anddfn
.I started resetting styles when I noticed that I was consistently clearing out
font-size
,margin
andpadding
.Ever since then, my browser-specific code (hacks and conditional comments) are pretty much gone. and my CSS is much cleaner and ultimately, lighter.
I'm not sure that with all the JS libraries we're using now a days that we should be overly concerned with 15 lines of CSS bogging down a web page's performance.
That's my2cents on it; some people use a reset, some people don't. No biggie.
Isn't the site adjusting in size due to the different text rendering used by those browsers. That is something I do not believe anyone can prevent.
Once again I will take the opportunity to reiterate my initial comments.....It doesnt matter if you use a reset or not....as long as you or your client is happy with the result then it is all gravy. I've had clients literally not care what their site looked like as long as it was clean in IE7. I personally strive to make all sites look good in all browsers without spending too much unnecessary time on it.
What is this thing about pixel perfection. Resets results in some authors using CSS repeated line after line like.
#id #id .class {}
#id #id .class {}
#id #id .class {}
Which makes style sheets very complex (the universal reset bug). CSS used cleverly is so simple (best viewed in Safari 3.1). Hopefully the CSS WG will allow empty strings in substring attribute selectors since I see many use cases for them.
Jonathan, you are part of the CSS eleven. Can you please consider that these (empty string) selectors should keep existing behavior in all browsers that support substring attribute selectors or for the CSS WG allowing me the time to show how they can be used. I begging.
My personal preference is to have a "base" style sheet, based on Eric Meyer's "reset.css", which specifies how I want things to look in the first place, rather than resetting then overriding again.
I then import more specific style sheets for other aspects of the site, such as layout / navigation / typography etc...
I find this method actually reduces the size of the additional style sheets, as I only need to tweak the properties I want to change, rather than redefining everything again and again. (This is just my personal opinion, btw.)
I have put up a page on my personal website, jdclark.org, if anyone wants to take a look:
<http://jdclark.org/tests/base.css>
@ Jordan
You say how you want things to look in the first place. So a base style sheet is how you want a page to look?
You are knocking down margins and paddings and building them back up again. This is adding unnecessary CSS.
The design shouldn't really be about what you want but rather be open to the needs of the audience of a site. You are trying to have to much control and one reason authors desire such control is due to the expectations of a client or clients seeing the space on a web page as real estate.
Resize a page on the average site. Two bumps on text resizing and chaos breaks out (overlap).
Resets may have been of great help in 2001 but now we in 2008. IE8 is in beta and now we have a much improve consistency across browsers concerning margins and paddings. Let resets be a handy tool of the past and lets move forward into the future.
@Jonathan
I glad you have such a fantastic preview on this blog (and in real time). Helps me with my grammar. :-)
@Alan:
Firstly, thank you for taking the time to look at that example on my personal website. To answer some of your questions about my previous comment:
I'm not saying that this is how I want a page to look, rather how I want it to look in the first instance. I am aware that there is some redundancy in the style sheet: this is just to get a consistent starting point. I've never bought into the idea of "expensive" selectors — I mean, I appreciate a fast-loading and efficient website as much as the next guy, but can anybody seriously say that there is a noticeable difference in rendering times of pages that employ say, for example, the
*
selector?What I've tried to do is build a rock-solid "default" that declares everything explicitly, without leaving anything to chance. The perfectionist in me (and I suppose everyone else in the "vote yes for reset.css" camp) knows that without the user-agent's default styles applied, there will be some gaping holes (although the fear is admittedly irrational). It is just being thorough.
I think the best thing is for us (i.e. the entire web dev community) to agree to disagree on this matter. I respect both sides of the argument, and I believe there is a place for both methods — it's just a matter of taste, and depends on what the project requires.
I'm feeling a bit uncomfortable promoting something of my own here, but reading your post made me nod along until I realized that your reasoning is almost EXACTLY the same as I had myself before I created my and Robert Nyman's initial.css. It does a base "reset" that basically just fixes gross inconsistencies between browsers, but leaves all other default styling intact and brings font-sizes as close together as possible.
The end result is really just about 15 lines of CSS, and not heavy lines at that, but it works very well. I've found it to be all I need in each of my projects so far.
Well put. I completely agree.
The only advantage I can see is the (potential) decrease in cross-browsers issues. But after 5 years of CSS:ing I hardly run into them any longer anyway.
We tried different reset css style sheets on smaller and bigger sites. Until now we still don’t if we hate them or love them. To some extend it is a personal choice. Our goal was to find a way of styling that works for everybody at our company. We also tried some frameworks. No holy grail yet ;-)
I have worked with Eric Meyer's reset, built a site using Blueprint and reviewed 960.gs. I have stated this elsewhere, that using s CSS framework from a third party in a solo environment is overkill but using some base css that sets up a project starting point for you as an individual web designer makes a tonne of sense.
I think that if you are always using common elements with the same basic starting point that it is wasted effort to redo it every time.
Jonathan, I agree completely with the POV that pixel perfection is a waste of energy and that if a person is using browser x they are not going to go check it to see if it looks different in another browser. That is our job. If the site doesn't break or if there are rendering issues we haven't done our job.
I use a basic reset in the projects I do which is enough for me.
I use
simply because it saves me having to hack any browser related problems. I'm not bothered about pixel perfect matching across browsers, but some quirky behaviour can make your site look plain wrong.
I like to style my headings according to the the purpose and tone of the site, so specifying colours, sizes, margins etc. will always be a part of the process.
@Alan Gresley - a lot of users still browse with IE6, so the web is, in a sense, still stuck in 2001.
I've been doing CSS builds for about 6 years and am very comfortable reseting whatever I need to on a case by case basis.
I've recently taken to using Eric Meyer's reset but to be honest I've found it more trouble than it's worth, due to having to re-declare a lot of things later on. Personally, I find the effort of doing that far outweighs the apparent gains that are made in having the 'clean slate' -- chances are that the tweaks you need for differing styles across browsers will be required anyway, regardless if you reset them initially or not.
So I think I'll be ditching resets on future work.
@Jordan
Of course you wouldn't want your site to look that way. Re-read the part that I quoted ;-)
I understand where you coming from. Basically the user-agent style sheets of the various browsers are not consisted and mixed with bug behavior we can expect anything to happen (10% inspiration ~ 90% perspiration). But now we have Gecko 1.7~1.9, Safari 3, Opera 9.5 and IE8 all showing greater constancy with CSS2.1. This is happening now and soon (hopefully) we can say bye bye to the magical IE bugs and bye bye to Opera specials bugs (just to make it all the more challenging for us).
The rock-solid "default" which we all desire is that foundation to build a page on. This rock-solid "default" was first seen in Phoenix (Gecko 0.6) in 2002 since it was also greatly CSS2.1 compliant. It's a shame that it has taken 6 years for all the other browsers to catch up. You say that the web development community should agree to disagree on this matter, but truly what are we disagreeing about?
@Leon
2001 is one static point in the past. We have the present (April, 2008) and we have the future. Form the tiny developers, browser implementors and spec writers, there is 'something' sort of happening. It's like some chains and anchors are all holding some of us back in 1996. This is the year that browser Internet Explorer was release upon the wold. Some are constancy haunted by this scary though that we may have to be backwards compatibly with IE5 forever.
What I am suggesting to all the web developed community is to see over the horizon. Now already we have almost compatible behavior in Gecko 1.7, Safari 3, Opera 9.5 and IE8. No time ever in the history of the the web have all major browser versions been in beta. This is the year that the web can break those chains from the past forever.
The web is not stuck in the past. It's part of a collective mindset that is trapped in the past. The year is 2008 and if you believe it the future is ours for the taking.
Did you also participate during the naked CSS day?
You guys are off your rocker :)
But seriously, I can't believe no one's mentioned Tripoli yet. I've used it for several projects, and it's convincing me that reseting is the way to go. Obviously mold the reset to your specific project, but some of us still have to design for IE6 and other atrocities, so resets are a fantastic tool to have.
If we all used Firefox and Opera, then obviously we wouldn't need them, but to me it seems like a lot of the commenters here are forgetting that certain demographics and audiences still use crap for browsers...
What I'd really like to see is not a 'css reset', but rather a 'css equalize', which would make my customers using IE see the same thing I see when I build it in Firefox. Specifically to do with body content, such as how IE and Firefox handle lists or headings. If I were more of a CSS expert I might undertake to write such a file.
@Mike
Currently on the CSS WG list there is some discussion which started with this message on CSS2.1 User Agent style sheet defaults. The final style will allow implementors to standardize the default style sheet, thus the end for a need for a CSS reset.
This test case shows all the default margins for in-flow block elements. IE8b has come a lot closer with the other implementations especially with list defaults.
@Kris
I still design for IE6 and IE5 (they get the same style). You just have to understand the IE bugs and the possible workarounds if there are any. The same can apply to IE7 and IE8 or any other browser. That is why I call using CSS resets the universal reset bug but this bug doesn't affect the browsers but rather the CSS authors. ;-)
@Jonathan
Great Blog post. I totally agree with this.
Sheer simplicity. That's how CSS is meant to work.
Great post - I must admit that I still use a CSS Reset, but I configured it for my own needs.Maybe I should take your advice of "Less is more" into consideration.
What about teamwork and collaboration. Isn't it more difficult without a Reset CSS?
I don't see how anyone could not reset.
I have a reset I use for building scalable HTML websites:
* { margin: 0; padding: 0; border: none; font-size: 10px; }
* * { font-size: 1em; }
and then you have to set * * { font-size: 10px } for IE6, else it will die.
Then 1em is equal to 10px on all elements. The * * rule is required to stop inline elements spilling all over the place in FF.
PS Like your live preview, a classy implementation at last.
Your comments about "having to define more when using a reset" is the exact reason that I decided to create ChaoSS, which starts with Eric Meyer's reset, then builds the styles back up. This creates a "base style" that is much more similar across browsers than a simple reset (or no reset) can provide.
It's still very much in early development, but I have already used it for a couple of personal projects and have been very happy with how much faster I can develop interfaces.
Tell ya... (while I haven't done extensive research) if CSS resets keep you away and/or limit IE hacks and the like then they're a GREAT GREAT thing.
I hate hacks period so I tend to dumb down all designs to the point that no HACKS are required. IE's proprietary crap peeves me to no end! Hail Firefox... , etc. We keep having to put all this If IE > 5 or IE 6 or > IE 5 AND 6, ETC. If IE nothing -- NO HACKS. Maybe in IE8 they will have finally come on board -- maybe.
Very useful post. Thnx.
Jonathan, you are correct. CSS reset is conceptually incorrect. This and other flawed CSS usages will inevitably cost more in development, and lead to inferior user experience.
Interesting perspective. I think I will continue using some sort of rest, but I'm glad to know that it is not so mandatory, and we are still flexible.
As a designer, I just can't stand when I put all this time into a design, and it doesn't even look like that when it is rendered. I put a lot of time and thought into every element, so I want my time to pay off.
A great debate here with interesting perspectives. I haven't had occasion to use CSS resetting yet, but overall I agree with your philosophy, that instead of starting everything from scratch, it makes sense to account for variabilities in a secondary stylesheet.
I use CSS on my websites, but I never knew about CSS reset and how it keeps the consistency throughout different types of browsers, interesting and informative.
I have been completely unable to find any benefit to 'css resets'. Where, specifically, are there significant differences among browsers' default values that need baselining?
cheers,
gary
Greetings,
I have a question for the webmaster/admin here at snook.ca.
Can I use some of the information from your post above if I provide a backlink back to this site?
Thanks,
William
>> I then find myself declaring much more than I ever needed to just to get browsers back to rendering things the way I want.
Exactly. Thanks for summing up my feelings about this.
After looking at Meyer's site, now I know why I never used css reset! What's the point anyways? It seems to be redundant, and contradicts other styles in place. I cross browser test the hell out of everything, and always make sure when new browsers come out to test those as well. No point in using this css reset everyone speaks of.