Jonathan Snook raised the point of CSS resets, and being a designer of his calibre, deserves to be heard when he says anything. I certainly do, and respect his opinions. However, when he said that he doesn’t use a reset for his projects, I did a small double take. Surely in this day and age, a designer doesn’t (as he shouldn’t) stick to the browser default CSS definitions. No designer worth his salt will allow a pixel out of his control. So then why would he be any different?

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.

It is in-fact, the difference in rendering that causes designers¹ the hours of anguish. I resort to pixel designs and trap the entire layout within max-width constraints to compensate for high resolutions. Before I was introduced to the concept of a CSS reset, every list, headline, paragraph etc. tag needed to be set manually. It would reach a situation where I would get confused as to which style was acting on particular element — mine or the browser’s. With a CSS reset² in place, I know that the element will be laid bare until I explicitly define the styles for it. My lists don’t have a margin or a bullet. My headlines render with the normal font size of the browser until I set it. I sometimes use the same styles for different headline levels, which allows me to create hierarchies between sections in the code, while keeping the visual presentation constant.

The arguments against reset

The most basic argument that I see is that it adds to your work as compared to reducing it, because (after reset) one needs to redefine all the styles again. Sure, it doesn’t reduce your work, but I don’t feel that it adds to your work either. I find myself setting double space length line heights for all elements, because the browser default is terrible for readability when using smaller, more elegant fonts. This extra space needs to be supported by margins and paddings to be reduced to zero so that designs don’t look too spaced out. And this is fundamentally the function of a CSS reset.

Ultimately, it is up to the designer to choose which approach he wants to take. From experience, I can vouch that it is in fact, more work to fix a design to look almost the same as compared to resetting and re-defining styles to look exactly the same in every browser. I completely second Jonathan Christopher when he says:

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 … a reset stylesheet to me is more a piece you work on as opposed to work with.

Personal vision almost never stacks. Most often than not, you will find yourself setting your own values to variables to get them to behave, in which case, it’s always better to start from a zero.

Personal choice

I have seen my work become easier (perhaps not reduce), and am very happy with getting all my elements to behave by adding just one import rule to my CSS. But to each designer his own I guess, and it depends on your comfort and skill factor. If you’re as crazy about micro-management as I am, it’s certain you will welcome the one line aid.

Hopefully, in the future, most of the inconsistencies will become constants, which will help us reduce our reset definitions to the minimum. But until then, I am pushing for greater adoption.

Currently, there exists no mechanism to select the parent of a matched child selector. There is no look ahead, like in regular expressions or XPath. This sucks, because it means that you have to define additional styles to affect parents, and parents with specific children differently. Two methods strike me as do-able at the moment to achieve what we are trying to do, and they both use Javascript, which wasn’t meant to do things like this.

Bottom up

In pseudo-code, we can do:

children = get_elements_by_tagname('xx');
for(i in children)
    if(children[i].class_name == 'yy')
        /* do something to "children[i].parent" */

Which means that if we want to style the parent of all a.child tags, we need to get all the a tags (time lost looking for unnecessary tags), check their class name for the required condition class (time lost iterating through unnecessary tags) and finally apply the styles to its parent. A simpler (and possibly faster¹) way would be to use $('parent child').parent() with jQuery, but that will require including a library for just one or two statements.

Alternatively, you could also get all the parent elements, and based on the child match, add a class to the parent. Then, in your CSS, a definition for that class will style your parents appropriately.

They are both clunky methods to do something which I am sure doesn’t need too much effort to implement natively. By the looks of it, this will not be included in CSS3. Looks like a job for Textual!