We’ve been using css as the presentation layer of web pages for quite some time. I’ve personally been using it for about 10 years and like many, much of my css practices were developed nearly as long ago. Is it time to change those practices?
Nicole Sullivan thinks so and I have to agree. She’s been giving presentations about our flawed css practices for at least the last year, and I think longer than that.
Last week I talked about how I’d like to organize css files around different aspects of design and mentioned a few css related topics I wanted to cover in the coming weeks. This is the first of those posts.
Our Flawed CSS Practices
Above are the slides for Nicole’s presentation on css flawed practices. I couldn’t get the video to embed here, but the previous link will take you to it. The video is 35 minutes long and worth a watch if you want the complete picture.
Though some of the specifics have varied from presentation to presentation, Nicole’s thoughts come down to a handful of different concepts. Below are practices the industry has held for years that perhaps need to change.
- Sites need to look the same in all browsers
- Pixel based sites are bad
- You should never add non-semantic markup
- You should use descendent selectors exclusively
- Classitis is bad and to be avoided at all costs
I hope we all agree that as an industry we’ve accepted that sites are never going to look the same in all browsers no matter how hard we may try and we should take a more progressive enhancement approach to development.
I disagree with Nicole’s idea about using pixels, though. She’s seeing this entirely in terms of page zoom and considers the move to ‘em’s and other relative measurements as no longer necessary.
The ideas behind responsive design and designing from the content out are right to call for more relative based measurements for most things.
Let’s look at the last 3 items on the list in a little more detail.
Descendent Selectors
We’ve been taught for years that best practice is to use descendent selectors to style our html. However this approach can become difficult to maintain and even lead to possible performance issues.
For example you might set styles on your generic h2. You then want the h2s in your sidebar to look a little different and further complicating matters you want a specific h2 in the sidebar to look different still
h2 {font-family: "Helvetica"; font-size: 1.2em; color: red; margin: 0} #sidebar h2 {font-family: "Georgia"; font-size: 1em; color: #000; margin: 1em 0;} #sidebar .related h2 {font-family: "Helvetica"; font-size: 0.9em; color: red; margin: 0} The above isn’t overly complicated, but it’s not too hard to imagine it becoming more and more complicated as you create ever more specific selectors that need to be overwritten. Later a change needs to be made and you have to write even more specific selectors or worse add an !important declaration, because you can’t figure out how to make something specific enough to take hold.
I’m sure you’re written the occasional
#sidebar .related h2.boxed ul ul a {styles here;} or something like it before. I know I have. I try my best to start with the least amount of selector specificity as possible when writing general styles, but that only postpones the problem. Our way of doing things sometimes leads us into specificity conflicts.
Semantic Markup
The basic idea behind semantic markup is to reinforce the meaning of the content being marked up. For example if you want to include a quote, you’d use blockquote tags. You could use an ordinary paragraph and style the paragraph to look like a blockquote, but that carries less meaning. Similarly you wouldn’t wrap an ordinary paragraph in blockquote tags and then style the blockquote to look like a paragraph.
Semantic markup and classes are generally a good thing because:
- They’re cleaner and clearer to read
- They’re easier to maintain
- They’re more accessible to devices
- They’re more search engine friendly
- They communicate more information
Does this mean we can never stray from semantic code?
Consider grid frameworks with classes like grid_7 and container_12. They aren’t semantic because they don’t describe the content. Instead they describe the presentation of the content. Still they can be a great benefit to designers in developing, reading and maintaining the code.
While I do think semantics are good and important I also think it’s ok to add some non-semantic code We don’t need to be 100% semantic at all times. Better is to understand how and where semantic elements can help in order to decide when and where to use them. We should strive toward semantic use of html without being a slave to it.
Classitis
One way to avoid the specificity problem that comes with using descendent selectors is to use more classes, especially if you’re not against using markup that describes presentation.
For example you might create a generic frame class to serve as a frame around some images on your site. Those images get class=”frame” added and those meant to be seen sans frame won’t have the class. Right away this reduces specificity issues as we don’t have to write and overwrite css styles on different parts of the page.
Later you may decide that some frames will be more sleek and modern and others will be more decorative. The styes common to both can remain in the basic frame class while the styles differentiating each get their own modern and decorative classes.
< img src="" alt="" class="frame modern" /> < img src="" alt="" class="frame decorative" />
.frame {styles common to both;} .modern {styles for modern only;} .decorative {styles for decorative only;} In Nicole’s experience using classes in this fashion greatly reduces the amount of css we end up writing. This naturally plays out more the larger your site and css. On Facebook they were able to realize a 19% reduction in css (after gzip) and a 44% reduction in html (before gzip). You and I might not see the same results, but we’d likely see results.
There’s something very logical to using classes like this. We can create presentational objects that can easily be reused across a design. Again think of the grid systems or my frame example. At the same time there might be a downside in that we’re now coupling our html and css more.
Part of the idealized beauty of using css for presentation is the thought that with a few changes to a css file we can completely redesign everything on a site. If we’re adding all these extra classes does that cause problems? It would be hard to change a 12 column grid into a 16 column grid without changing the classes that were added through the html for example.
In practice though this idealized version of css doesn’t hold up. Some things we can easily change site wide by making a few css tweaks, including some layout changes. More often a complete redesign calls for structural changes to the html. Your 12 column grid doesn’t become a 16 column grid through css changes alone. It’s going to require html changes.
This doesn’t mean we should all go class crazy and use them for everything, but it does mean we don’t need to run away from using classes entirely. Somewhere in between there’s a good balance of using classes as presentational objects.
Summary
You may or may not agree with all or any of the above as flawed practices. Overall I tend to agree with what Nicole is suggesting and where her ideas lead, which is essentially to build sites with a reusable set of classes instead of sticking with descendent selectors.
I do have my reservations here and there. I don’t want to overdo the classes, but I do think a class-centric approach to html and css is generally a good one that allows for more design flexibility along with easier maintenance and a reduction in code.
I can see where it could lead to some difficulty if you’re looking to make wholesale changes as in a redesign, but more and more I think you’d encounter the same difficulty whether you’re using classes or descendent selectors and this probably isn’t a significant issue.
Mostly I think these ideas and questioning our practices makes a lot of sense, particularly now. The last year or two has seen so much new thinking in how we design and develop sites that now is the time to question much of what we hold as true and see if it still applies.
This rethinking leads us to some new concepts. As a reminder here are some topics I want to look at in the coming weeks.
- abstracting css
- oocss and smacss
- css preprocessors
What do you think? Is Nicole right? Is it time to change some of our long held practices? Is there a danger in doing so?
