Resets – time to stop?

This piece should really be titled: Resets and Frameworks – time to stop?
As the two tend to go hand in hand when looking at the cons for following this approach.

Taken from Smashing Magazine- under the section of cons quotes a paragraph from Jonathan Christopher ( to be noted is the fact that Jonathan Christopher does not dismiss Frameworks out of hand )that echoes my sentiments and major worry where Frameworks are concerned:

You develop sites upon a framework, not upon the solid knowledge of CSS.
“A big problem with frameworks is when up and coming developers attach themselves to a framework as opposed to the underlying code itself. The knowledge gained in this case surrounds a specific framework, which severely limits the developer.” [Please Do Not Use CSS Frameworks10, by Jonathan Christopher]
Smashing Magazine – css frameworks css reset design from scratch

I was reading a thread on Devshed CSS forum regarding the use of CSS resets and the contra arguments to the use of them pretty much followed my current thinking.

I had used the classic early reset, the universal selector, that amounted to this simple ruleset * {margin:0; padding:0;} declared at the top of your main styles from the very early days before many had latched on to it’s use and long before Meyers reset or Yahoo’s version; I believed it was useful and helped keep consistency between browsers, this is a view that I now acknowledge wasn’t based on enough firm reason or testing it just felt right!

As time moved on more and more people started to use the reset principle, possibly due to people like myself on coding forums advocating their use, a little while later after it had seemed to become a convention set in stone to use the reset approach Eric Meyer took it upon himself to do some research and produce a better method this was due in pert to the perceived problems that resting values universally were thought to produce, one of which was a problem with form controls when margins and padding were removed.

Meyers reset was of a somewhat detailed and involved nature, and was the end product of a lot of testing of all elements and their handling of certain properties, needless to say it became very popular and used fairly widely. I personally was never too keen on it as it simply felt far too weighty and I couldn’t quite believe that so many elements benefited from all those properties

We discussed the merits of resets and in particular comment was passed on Meyers reset here at CSSCreator 34411#comment-145634 this gives an idea of a few of the de-merits involved and of the feeling of a few? in regards resets.

Following a reset policy invariably means that one has to then deliberately set certain properties that had now been removed, in light of that my approach was always to then state default properties on generic elements, for example margins on paragraphs via a generic rule such as p {margin: .6em 4%;} or something similar; but this is something that I would do regardless! so what point to the reset? I have achieved the goal of giving all browsers a stated value to use. this is one of the reasons that I now have changed my views on this subject, as seasoned CSSers we know we need to control certain aspects of elements when styling that should be sufficient to handle any issues, issues that are not at all clearly defined in the first place.

So it’s my humble belief that it is time to move away from reset policies and back to controlling things as one progresses through ones styles, by all means though do set your generic defaults on elements such as UL, H#, P, etc.

Update: Recently came across this blog post No CSS Reset – snook.ca that expresses a similar take on the subject.

Comments are closed.