Popular ‘CSS Reset’ Stylesheet Gets an HTML5 Makeover

Scott Gilbertson — Tue, 04 Jan 2011 16:11:54 +0000

Woolly, the CSS sheep.

Eric Meyer introduced the web to the concept of a “reset stylesheet.” The goal of a reset stylesheet is to make sure every browser starts from the same set of display defaults, correcting differences in default line heights, margins, heading fonts and so on. Now Meyer has updated what’s probably the web’s most popular reset stylesheet, the famous “Eric Meyer Reset.”

You can grab the latest version of Meyer’s reset stylesheet from his website (note that Meyer’s main reset page still hosts V1, for the updated version you’ll need to copy and paste from the linked blog post).

The latest version of Meyer’s reset stylesheet dispenses with a few CSS rules that probably aren’t necessary anymore — for example, the font selector in the first reset rule — and adds some new rules to handle HTML5 elements in older browsers.

Meyer also corrects what he considers the biggest mistake of the original code — setting :focus to invisible. The idea behind the rule was sound — reset :focus so authors can easily define their own styles. The problem was that too many people did not define their own focus styles. That meant thousands of websites that simply copied and pasted (or hotlinked) Meyer’s stylesheet, without really reading it, wiped out all the :focus styles.

In the new version Meyer has commented out the entire :focus rule to avoid obliterating :focus styles on sites that simply copy and paste the code. Those that take the time to uncomment the rule will, one hopes, notice the comment telling them they need to define their own visible focus rule.

If you’ve been using the also very popular HTML5 Doctor reset stylesheet, you’ll probably notice some similarities in Meyer’s new effort. Both make excellent starting points for those that have grown accustomed to reset stylesheets. Just keep in mind that Meyer’s update is still a beta release so, as he writes, “use with caution and test with abandon.”

See Also:

Advice From the CSS Guru: Embrace Prefixes

Michael Calore — Tue, 06 Jul 2010 19:23:04 +0000

Sisyphus, by Max Klinger. The four ladies up top are named Gecko, WebKit, Trident and Presto.

Vendor-specific CSS prefixes have been popping up in all the shiny and fancy CSS 3 demos of late. Microsoft IE 9, Firefox and Safari have all been using them to show off their latest CSS tricks, and you’ve probably already formed an opinion about them.

Web purists scoff at prefixes, since they add to the amount of coding and testing required just to get something to show up consistently across browsers. Repetition and bloat aren’t welcome in this camp. But those who live on the bleeding edge see them in a different light.

In his latest piece for A List Apart, noted CSS scholar Eric Meyer argues that vendor-specific prefixes should be welcomed, not reviled: “We ought to praise vendors for using prefixes, and indeed encourage them to continue,” he writes.

Meyer’s argument is simple. Coding a stack of prefixes into your CSS is not ideal, but it’s better than the alternative of using inconsistent CSS hacks or having to sniff for user agents to serve up totally different styles to different browsers.

He also argues that, “prefixes should become a central part of the CSS standardization process… I believe that prefixes can actually accelerate the advancement and refinement of CSS.”

And it makes sense. Consider the author working with some brand new CSS property. At this point in its young life, all of the browsers are implementing the property, but all are doing so differently. The author can use the property — with prefixes — and gain the utility of whatever magic that CSS property is supplying without having to worry about their pages breaking in such-and-such browser.

These temporary hacks dwindle over time, Meyer writes.

As time goes on and implementations become consistent, browsers will drop the prefixes. From then on, authors will be able to write one line for border-radius instead of six-plus lines of CSS. Without them, we’re just waiting for the next botched implementation that forces us to support it through hacks for years upon years.

Definitely check out the whole article. It draws some interesting conclusions. Meanwhile, how do you feel about prefixing in CSS? Does it bother you, or do you agree with Eric that the practice will only make everything more interoperable in the future?

See Also:

Webmonkey » Eric Meyer

Popular ‘CSS Reset’ Stylesheet Gets an HTML5 Makeover

Advice From the CSS Guru: Embrace Prefixes