Thom's House

I developed my own CSS reset a while ago, and I’m pretty happy with how it’s working, so I thought I’d share it.

The concept of a “CSS Reset” is embarrassingly new to me–I only read about them a month or two ago.  Of course, 90% of what a reset does, I have done manually for years, but I stupidly never thought of separating the styles out that way.  When I read about resets, I was initially turned off because many of them seem way too aggressive.  (Upon searching for validation, I indeed found that it I wasn’t the only to dismiss resets as a bad thing.)

I’m a stubborn person, but fortunately I seem to be capable of talking myself out of stubborn positions.  A week or two back, I decided to try out the use of a reset, to see (A) if I liked the setup, and (B) if it seriously borked any of my recent work.  Looking around, I didn’t find any that did exactly what I wanted a reset to do.  The closest was a reset unofficially credited to Shaun Inman, although it appears to be itself modification of the popular YUI reset.  It was as good a place as any to start, so I began to flesh out my own personal reset script.  Here’s what I came up with:


/* "Voodoo Child" CSS Reset by Thom Stricklin. Based on W3C defaults, YUI and work by Shaun Inman. */
body,div,dl,dt,dd,ul,ol,li,h1,h2,h3,h4,h5,h6,
pre,form,fieldset,input,p,blockquote,table,th,td,embed,object {
padding: 0; margin: 0; outline: 0; }
table { border-collapse: collapse; border-spacing: 0; font-size: 1em; }
fieldset, img, abbr { border: 0; }
address, caption, cite, code, dfn, th, var { font-weight: normal; font-style: normal; }
caption, th { text-align: left; }
h1 { font-size: 2.0em; }
h2 { font-size: 1.50em; }
h3 { font-size: 1.17em; }
h4, h5, h6 { font-size: 1.0em; }
h1, h2, h3, h4, strong, b { font-weight: bolder; }
h5 { font-weight: bold; }
h6 { font-weight: normal; }
q:before, q:after { content: ''; }
a, ins { text-decoration: none; }
sub { vertical-align: bottom; font-size: 0.67em; }
sup { vertical-align: top; font-size: 0.67em; }

/* Slight Return. These settings are more likely to change from project-to-project. */
h1,p,blockquote { margin-top: 0em; margin-bottom: 0.5em; }
h2,h3,h4,h5,h6 { margin-top: 1em; margin-bottom: 0.5em; }
ul, ol, blockquote, dd { margin-left: 5ex; }
.block-list li { list-style: none; }
.inline-list li { list-style: none; display: inline; }

A few things my reset does differently:

• This is a reset…  and then some.  The new rules I set are too modest to consider a CSS framework by any means, but they do go beyond a standard reset.  For those who would prefer just the reset, just take out everything after the “Slight Return”. (Yes, I am a dork.)
• I do not set all headers to 1em.  Rather, I went with a mix of the W3C “default” values and a little common sense: It’s pointless for H5 and H6 to be smaller than 1em so, instead, I decrease their font-weights.
• I treat H1 differently than other headers.  The train of thought is that H1’s will most likely appear at the top of the page, and so will not require a top-margin value.  H2’s and beyond will appear in the middle of page content and will probably look better with some extra separation.
• I do not reset the default list styles.  Lists-as-layout are very popular now and rightfully so, but they’re still great for normal lists–like this one–too.  I do provide “block-list” and “inline-list” class declarations for quickly & easily achieving headless lists.  I’m not sure how useful they are, though…  I’ve already encountered a case of a list that will be displayed as block for screens, but inline for iPhone/mobile.
• I fiddle with the display of sup/sub tags.  This behavior is out there in other reset scripts, but unfortunately I did not save my source for this partiicular solution…  Sorry!

I hope this reset script might be of some use to others.  More importantly, I hope this might help to open some minds about reset scripts.  They really are just a set of tools we each can choose to use…  or not use.  But we can forge our own tools.  We can write our own resets to our liking, so why not?

There has been a little buzz lately about what the next version of Firefox should look like, and it’s certainly different.  The latest idea seems to put the tab, and tab-like items such as apps and workspaces, in the sidebar.  It’s either innovative, or an ode to iTunes, depending on who you’re talking to.

I personally oppose making our browsing experience dependent upon “workspaces” or categories…  It would take too much work for everyday browsing, it’s presumptuous to expect it would actually match most people’s browsing patterns, and it’s only adding another layer of organization to the browser, as tabs (or whatever tabs become) are still in there somewhere.  Workspaces could be useful for advanced users, but let’s not build our browser around them.

I do, however, like the general trend towards moving things into the sidebar.  As I commented on Mozilla designer Aza Raskin’s blog, there are many reasons to consider this a good move.  In fact, I say let’s take things to the next step and move the entire browser UI into the sidebar.  I spent an evening in Fireworks layout out such a design, and here’s what I came up with:

I probably went just a bit too extreme on how compact I made the sidebar (which of course, ought to be resizable anyway) but I wanted to drive home the point: done right, this exodus to the sidebar can improve simplicity, usability, and aesthetics.  The sidebar is the new awesome bar.  I’ll break things down by component:

• Address Bar/Awesome Bar: Firefox (and Chrome, too) have gone a long way to making the address bar more useful, and ubiquity will take us even further down that road.  But there’s still one big problem: it’s a real-estate hog.  Most of the time, if I ever even type in an address these days (more likely I’m following a link or a book mark), I just type, press enter, and forget about it.  Why is it constantly hovering over my window?   When it doesn’t have focus, it should condense down and slide into the sidebar.  Give my web page the full height of the screen to work with.  When you click into the space–boom–it slides back out for you.  It might also be a good idea to provide a delete button on-hover (a la OS X/iPhone search fields).
• Back, Forward, Reload/Stop, and Home: The only four buttons we need.  Even in the current Firefox incarnation, these would easily fit into the sidebar, so why not?
• Apps: Not sure where this idea originated, but it was on Aza Raskin’s mock-up, and I think it’s a great idea.  I hope these are not just “supertabs” in that they stick to the top, but that they provide additional functionality: Available in all windows, always open in the background, personalize the name in sidebar, etc.  I think the option to “maintain a separate cookie/session” for an app would be a neat idea too, as we could then maintain a “Personal Gmail” app and a “Work Gmail” app running without interference, and without the need for an addon.  I also think that Mozilla, Google, and Apple should work together on some sort of web application notification system (some extension of the dom or the navigator object).  As we think of web sites more and more as applications, we need to have the level of interactivity that we’d have with desktop apps, and flashing a message in the title attribute just doesn’t cut it any more. We should have both numeric notifications (i.e. 9 new messages, as pictured above) and Growl-style textual notifications.
• Tabs: Not much to this, except I do think it’s important to give users a “show all tabs” button.  Let’s not be so concerned about doing things “the Firefox way” (differently) that we fail to acknowledge a good user interface element when it comes around.
• Bookmarks, Feeds (Not Pictured), History, Addons: What’s great about this sidebar approach is that it really unifies the interface.  All of these components can look the same and function in the same or similar manner.  It also leaves it so that browser components are competing with each other for real-estate, not with the page content.  I envision most of these components (except bookmarks) being collapsed by default, and expanding on-click accordion-style.  They can either take up as much space as they need, or take over the whole sidebar, collapsing the other components.  But once you click away from the sidebar, they collapse again.
• Themes/Styles: I know absolutely nothing about the current means of theming Firefox, but make this sidebar CSS-driven and I could create an entirely new theme from scratch in about five minutes.  In fact, we could build customization into the browser (think similarly to Twitter’s interface) and let users set their own colors, backgrounds, etc.

A word of caution: let’s not throw out the baby in favor of trendy new bathwater.  In my experience, most Firefox users do not use 20 tabs at once.  They do not keep certain pages open, app-style, at all times.  They’re perfectly happy with the current user interface, and if we completely abandon it, they will balk and move to Safari or Chrome or even IE8 for a more familiar experience.  (See: Winamp.  How many of us switched to iTunes when the ridiculous Winamp 3 UI came out?)  So we need to think out a way to make this new UI work both ways, and probably give users the option when they upgrade: UI elements at top (Firefox 3) or on the side (Firefox 4).

That said, if the next version of Firefox resembles this in any way, I will be eagerly awaiting the 4.0 beta.