Chapter Ten: CSS Resets & Frameworks
Without a style sheet, your browser displays web pages as a single long paragraph of text, all with the same size and weight. This may come as a surprise, because when you view a page in your browser before adding your CSS, it isn’t displayed that way. Headings, paragraphs, and other block-level elements are displayed as blocks with margins and padding, and at various text sizes and weights. Links are colored (probably blue) and underlined. This all happens because the browser is using a default style sheet—and, of course, each browser’s default style sheet is a little bit different.
CSS Resets
Browsers apply the default style sheet first, and then add on any preferences a particular user has set (such as custom default font sizes). Only after the default style sheet and the user preferences are added does the browser use the styles you’ve defined for the page via inline styles or any embedded and linked style sheets.
Variations between browsers—especially those caused by the browsers’ default style sheets—can make it very difficult to maintain design consistency across browsers. In the last few years, developers have begun to use reset style sheets to deal with this problem. Reset style sheets create a consistent, cross-browser baseline for font sizing, element margins, padding, line-heights, and so on, thus providing a smooth foundation for the all the styles called for by a particular project. To use such a style sheet, a developer simply links to it from every page on a site or includes it in one of the site’s universally used style sheets.
Benefits of CSS Resets
Most designers and developers tend to work with a single browser during development, switching to other browsers only when it comes time to finish and test the markup and styles. The implicit assumption associated with this approach is that the default styles for the browser we decide to work with will be similar to the default styles of other browsers. Default style sheets, however, can be sufficiently different as to create both subtle and not-so-subtle problems. Using a reset means that we’ll never again develop a complex style sheet, only to find problems caused by variation of default styles across browsers that require considerable effort to fix.
The core philosophy of CSS resets is that it’s safer and easier to explicitly declare any style you use, rather than relying on (and guessing about) implicit styling. That said, most resets do rely on some core browser default styles. For example, most resets trust the default value of the display property rather than explicitly declaring that headings, paragraphs, and other block-level elements use display: block; that strong, em, and other inline elements use display: inline; that list items use a display: list-item; and so on.
Arguments Against Resets
Critics of the reset technique argue that common features of prominent CSS reset files, such as setting the margin and padding of every element to 0, or using the universal selector (*) as some resets do, can create considerable performance overhead for the browser. This is why many common reset files no longer use these performance-intensive methods.
Another argument against resets is that they add another server request, which can affect site performance: reducing the number of external resource links in a page is one of the best ways to improve performance. As noted in Chapter 4, there are many simple ways to improve site performance when using CSS, including amalgamating each page’s CSS into a single style sheet whenever possible. Increasingly, developers have begun to add their reset styles to the main style sheet for their sites.
Performance problems aside, there are also philosophical reasons to avoid resets—on some projects, at least. Respected web developer Jonathan Snook recently explained why he doesn’t use resets:
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.
—www.snook.ca/archives/html_and_css/no_css_reset
Even if you share these concerns, however, you might choose to use resets in a limited way, explicitly resetting default styles for only those aspects you’re particularly concerned with. For example, developers very frequently set margin and padding to 0 on block elements like paragraphs and headings, while leaving out resets for things like the type of list bullets and the font size of headings.
In the end, the reset approach has both adherents and critics among well respected development experts. As with so many choices in web development, you’ll need to consider the practical benefits resets can offer and decide whether or not to use the technique based on the needs of your particular projects.
What Do CSS Resets Look Like?
CSS resets often look something like this one, which is excerpted from a reset developed by leading CSS expert Eric Meyer:
You’ll notice that this rule sets the margin, padding, and border for many elements all to 0—which means that after this reset is applied, the width and height of any element will be determined only by its content. The rule doesn’t take the once-common approach of using the universal selector (*) to set these values, because as mentioned earlier, this method can harm site performance. Meyer’s rule also removes any default font-family, font-weight, and type size that the browser style sheets might apply. These are the core elements of most resets.
Common CSS Resets
If you decide to use a reset, get to know it first. Many resets have such subtle effects as removing a browser’s default list-item padding, thus making list items flush-left with the rest of the content for a page. If you don’t know your reset well, it can be difficult to trace the exact cause of effects like these.
Here are two of the most commonly used resets.
Eric Meyer’s Reset Reloaded
meyerweb.com/eric/thoughts/2007/05/01/reset-reloaded
Eric Meyer is perhaps the preeminent expert on CSS development. His reset is based on years of experience and a deep knowledge of the differences between how browsers render pages. Did you know that some browsers indent list-items with padding, while others use margin? Eric does. He encourages anyone who uses his reset to do so as the basis “for their own resets and for deeper thinking about styling and browsers.”
Yahoo Reset CSS
The Yahoo User Interface Library (YUI), a CSS framework we’ll look at shortly, includes a reset file that can be used independently of YUI. Yahoo describes the reset as follows:
The foundational YUI Reset CSS file removes and neutralizes the inconsistent default styling of HTML elements, creating a level playing field across A-grade browsers and providing a sound foundation upon which you can explicitly declare your intentions.
A-grade browsers is a term Yahoo uses to describe the set of browsers that get the full HTML/CSS/JavaScript/DOM experience, and the classification is based on browsers’ technology support and market share.
Both of these popular resets set the font size and weight of all elements to the same setting, and both override the browser’s default setting of strong elements and headings to bold. They also set the margin and padding of most elements to 0. One important way in which they differ is the :focus state. Meyer’s reset removes any outline from any element in the focus state, and because this is an important accessibility feature, he recommends setting your own focus styles.
The Do-It-Yourself Reset
This isn’t another third-party CSS reset, though there are others. Instead of offering a giant list, I’d like to suggest that you consider developing your own reset based on your specific practices and needs. Building your own reset means that you’re necessarily aware of all of its implications, and it also means you can be very specific about which aspects of default browser style sheets you want to trust, and which you want to explicitly override with your reset. Finally, developing your own reset decreases the chance that you’ll be hit by some subtle and hard-to-find “gotcha” in a third-party reset.
CSS Frameworks
As we saw in Chapter 5, when it comes to DOM scripting, many developers have begun to use libraries to provide common functionality and gain access to a higher-level and more user-friendly set of tools than that offered by low-level DOM programming. CSS frameworks attempt to provide the same thing for CSS. Whereas CSS resets focus on the specific challenge of creating a baseline style across all browsers, CSS frameworks have the much more ambitious goal of providing reusable core CSS styles for typography, layout, and other design features.
Before looking at popular frameworks in detail, let’s consider common arguments in favor of and against CSS frameworks as a whole.
For and Against CSS Frameworks
CSS frameworks offer many real-world benefits, including:
• The ability to reuse code in different projects, rather than crafting layout CSS and HTML individually for each project from scratch
• Shorter development timelines, as a result of code reuse
• Built-in cross-browser layout compatibility—like JavaScript libraries, CSS frameworks are built with browser differences in mind
• Easy implementation of complex, grid-based layouts
Common criticisms of CSS frameworks include the suggestion that because frameworks typically comprise several CSS files, they may harm site performance, as well as the notion that frameworks can lead to a “cookie cutter” approach to page markup and design. The first objection can be addressed by amalgamating and compressing files, but the second is harder to get around. Respected web developer and author Jeremy Keith recently commented on the issue using the example of Blueprint, a popular CSS framework:
I don’t see myself using Blueprint. It just seems too restrictive for use in a real-world project. Maybe if I’m building a grid-based layout that’s precisely 960 pixels wide it could save me some time, but I’m mostly reminded of the quote apocryphally attributed to Henry Ford about the Model T: The customer can have any color he wants so long as it’s black.
There’s also quite a bit of debate about using a grid-based approach—a pillar of page layout in print design—in the fluid world of web design. Jason Santa Maria, a highly regarded web and print designer, frames the problem this way:
For a long time we’ve been looking at web design through the lens of print design, and while some of the traditional design practices can make the jump to the screen, some cannot. The screen brings with it different kinds of challenges for visual design, some of which occur exclusively in interactive media. It’s unrealistic to think our old methods can fill in all the gaps, but new interaction patterns and visual languages emerge everyday.
—www.jasonsantamaria.com/articles/whats-golden
All the concerns I’ve mentioned are worth consideration, but the biggest potential problem with CSS frameworks—especially grid-based frameworks—is that they enforce the use of specific markup to achieve certain layout effects rather than genuinely separating markup from presentation. They also tend to use non-semantic class and id values such as grid_18 and container_12 as part of their markup.
Still, regardless of your position on using CSS frameworks for production code, they are a very popular and highly efficient method of prototyping, so even if you choose not to use them for production code, they’re well worth exploring for prototyping alone.
Common Frameworks and Their Uses
Let’s take a quick look at some of the most common frameworks and their specific uses.
Blueprint
Originally developed by Christian Montoya and now maintained by a strong open-source community, Blueprint is one of the earliest and most well known CSS frameworks. It features a CSS reset, typographic support for font sizing and baselines (helping designers create “vertical rhythms” of text), grid-based layouts, form element styling, and print styles support. It also includes a web-based grid layout builder for WYSIWYG-style grid layout development, which is very useful for prototyping if nothing else. Blueprint is designed for all modern browsers, including IE 6 and higher.
Potential problems with Blueprint include its lack of real support for elastic or fluid style layouts (though there is a plug-in for creating these kinds of layouts), as well as its completely non-semantic naming scheme for classes (it uses names like push-12 and prepend-8).
YAML
Yet Another Multicolumn Layout (YAML) (which is not to be confused with “YAML Ain’t Markup Language,” a data serialization language similar to JSON) is another popular mature CSS framework. YAML is widely considered to have better support for elastic and fluid layouts than Blueprint, though it lacks Blueprint’s support for sophisticated typographic styling. It also has a visual layout builder, and supports all contemporary browsers from IE 5 up.
YAML has wide support among CMS and blogging systems like WordPress, Joomla, Drupal, and Expression Engine.
YUI Library CSS Tools
Yahoo’s User Interface library, which we touched on briefly in Chapter 5, is much more than a CSS framework—it’s really more like the frameworks traditionally used for desktop application development. The library features several CSS tools, including a CSS browser reset, support for sophisticated grid-based layouts (with a visual grid builder), and typographical support. If you are already using YUI for its JavaScript features, it is well worth considering as a CSS framework.
Other Frameworks
There are many other frameworks with their own strengths and weaknesses. Two particularly well-known ones are the 960 Grid System (www.960.gs), a framework with visual tools for building grid layouts based on a 960px width, and emastic (code.google.com/p/emastic), which provides fluid and fixed layouts, along with typography.
Many organizations also build their own frameworks based on their particular needs; this brief selection is intended to give you an overall a sense of the kinds of frameworks available.
The Wrap
Whether you approve of them wholeheartedly or maintain some reservations, CSS resets have taken root as a common development practice. If you decide that your next project does call for a reset, they’re easy to find. If you’re using a CSS framework, it will almost certainly come with a reset of its own, and if you’re not, there are many popular third-party resets available—not to mention that developing your own is not particularly difficult or time consuming.
CSS frameworks are also extending our notions of what we can easily accomplish with style sheets, promising greater productivity for developers who use them, as well as access to sophisticated typographical styling and grid-based layouts.
They’re also controversial, and rightly so. CSS frameworks are based on the idea that markup should be built around an element’s position on a page, rather than around the element’s content. In that way, the non-semantic, deeply nested markup produced by these frameworks harkens back to the bad old days of table-based layouts. As a consequence, many experienced and thoughtful web developers are less than enamored of frameworks, especially when it comes to grids. Whether or not you should use them depends, as always, on the parameters of your particular projects.
On the other hand, even if you’re quite opposed to using frameworks on live sites, they’re hugely helpful for rapid prototyping, so you’ll probably want to check them out for this purpose alone. All the frameworks mentioned here have strong communities, excellent documentation, and many example files, so you’ll find it easy to get a sense of whether a specific framework will solve the problems you face.
And now it’s time to move beyond the foundations of web development and begin to explore even newer—and more controversial—techniques and developments, beginning with Chapter 11’s in-depth discussion of HTML5.