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
{code type=css}
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}
{/code}
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
{code type=css}
#sidebar .related h2.boxed ul ul a {styles here;}
{/code}
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.
{code type=html}
< img src="" alt="" class="frame modern" />
< img src="" alt="" class="frame decorative" />
{/code}
{code type=css}
.frame {styles common to both;}
.modern {styles for modern only;}
.decorative {styles for decorative only;}
{/code}
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?
Download a free sample from my book, Design Fundamentals.
I’ve been following along in your recent articles examining how we craft our CSS. I’m somewhat familiar with OOCSS, though the more I hear about it, the more it seems like the way to code CSS. I’m in the process of finishing up a re-build of my portfolio, switching from a fixed layout to a responsive layout, and moving everything to run on WordPress. One issue I ran into during the rebuild is that there is a ton of CSS needed to handle all of the stuff WordPress can generate.
It really seems like an OOCSS approach can cut down all of this extra “crap” we end up having in our stylesheets due to handling issues with descendant selectors.
I hate to say it, but I know I’ve too, written a selector like your example, #sidebar .related h2.boxed ul ul a{}.
One of the biggest reasons I think moving towards using OOCSS is the way to go comes from the benefit it will have for mobile users. The more we can cut down our code, the better for them. With reduced file sizes, comes faster load times and less data consumption.
I do think your concerns about classitis are valid. Even with classes, we can have duplication, so it will be important to review our CSS and see where we can create abstractions.
Thanks Brett. I haven’t explored oocss or smacss in detail yet, but I have looked at both and understand the why behind them. I’m thinking moving in their direction is the right approach too.
The part of me that’s hesitant is in wondering about what happens during a redesign and having all those classes in place. I’m not so concerned with the boilerplate code as that’s going to change during a redesign anyway. I’m more concerned about individual pages and adding classes to the content that gets stored in the database.
For example I’ve added my share of html in general to posts here. Take most of the images here. Most will have width and height specified as it was the default way my blog editor adds images. Now I’m working on a responsive design for the site, but for the images to be responsive I’ll need to remove the height and width values on each.
My concern is with oocss I’ll likely be adding classes to elements in the content in a similar way to the image dimensions. At some point that could mean maintenance has to happen on a post by post basis instead of one time for the boilerplate.
My guess is I’ll be doing some searching and replacing in the database to make things quicker.
What do you think of Mark Otto’s (@mdo of Twitter Bootstrap fame) stance ( http://www.markdotto.com/2012/02/16/scope-css-classes-with-prefixes/ )? It may not be as dry, but it does seem more maintainable to me.
I’m trying to start employing OOCSS concepts now, and am pretty happy with it, but there seems to be a divide growing in the possible directions a front ender can go.
I also look forward to your SMACSS discussion, I’m diving into that now too.
Thanks for the link Jake. I hadn’t see Mark’s post before.
It’s an interesting approach. I kind of do something like that myself as a way to organize selectors and make them readable.
The prefixed approach takes away some of the flexibility of chained classes though. Instead of being able to style .button that could be used for both .success and .failure, you’d need to duplicate some styles across .button-success and .button-failure.
By the way I fixed your link. The )? at the end were getting included for some reason. A little extra space fixed the problem.
I am actually moving away from OOCSS as I move towards responsive design. In adaptive/responsive design, layout rules tied to the content as classes makes it difficult to fluidly change layout on different devices and screen sizes.
My CSS has instead moved to the classic best practices approach where styling semantic elements individually. However this presents us with the issue of organizing this mess of code. Using preprocessors the styles can be broken into Sass objects and applied to the elements themselves. This allows for the clean and orderly approach of OOCSS while the CSS and HTML follow traditional best practices. Also, I have noticed a dramatic drop in my file size.
Interesting Scott. I’m not sure I understand why the classes would cause any problem with responsive design though. I would think you could rewrite styles as needed via media queries the same as if you weren’t using classes. Is it just harder to keep track of what needs changing?
I too disagree on Nicole’s idea about using pixels.
I disagree with the semantic markup stuff you wrote about
“Consider grid frameworks with classes like grid_7 and container_12. They aren’t semantic because they don’t describe the content.”
Classes neither describe the content nor the presentation. They merely act as hooks. The markup is still semantic if we use classes like ‘grid_12’ etc..
this is a paragraph
and
this still is a paragraph
In the above markup, both the paragraphs have the same semantic value.
Furthermore, ooCSS never encourages non-semantic markup. When you follow the ooCSS or SMACSS approach, your markup can still be 100% semantic.
BTW, have you seen the BEM approach? – http://bem.github.com/bem-method/pages/beginning/beginning.en.html
I’m not sure I agree. The classname is describing something. grid_12 is describing the presentation of some content. If you start adding things like class=”red” to your markup you’re moving away from semantics.
I do think it’s ok to have the class describe presentation. There’s plenty of meaning communicated with grid_12. Semantics as I understand them have usually meant describing the content specifically. I’m fine not always doing that, but that’s where my content comes from.
I hadn’t seen the BEM approach. Thanks for the link. I haven’t had a chance to absorb it yet, but will. It looks interesting.
You’re absolutely right.
You wouldn’t use grid_12 as a class just as we wouldn’t use ‘clearfix’ as a class. It’s entirely non-semantic.
Futhermore, you should never have to edit your HTML templates.
Advocates for such usage make it painful for others to clean up their mess.
I can’t believe we’re still having this discussion. And please, for the love of CSS, stop setting font sizes in pixels!
Has anybody tried zurb foundation 3 grid system? We have just started moving into responsive design and found this framework worked really well, appreciate anyone else’s feedback on this? Were loving the fluid grid system, fixed width is becoming extinct!!!
I haven’t tried it yet. What did you like about it?
For css lover, some or most prefer to use class for the reason that you describe. but from the javascript developer point of view, the heavily use of class will gradually decrease the performance of the site.
You can still use ids for javascript hooks. I think the idea is to use classes as hooks for styling and ids as hooks for javascript.
Really nice post, some things I didn’t know about CSS, Thanks for sharing Steven.
Hi Steven 🙂 Probably it’s simplicity and ability to adapt on any platform, I found it easier to work with than the 960 grid system. If you haven’t tried it yet you can download it free under the MIT licence. Check it out!
Thanks Colin. I appreciate the info. I’ve definitely heard of Foundation, though I haven’t given it a look yet. I’m pretty sure I’ve got some notes about it somewhere in a post I’m thinking of writing. I will take a deeper look.
Thanks again.
Your welcome, please let me know if you make a post on this as I have just taken a massive interest in responsive design and grid layouts so would enjoy the read!
Will do. It might be a while, but if I do include Foundation in a post or maybe do one on responsive grid layouts that includes it, I’ll definitely let you know. There are enough out there now to give a few a try and see what I think.
The gravitational force that pulled me out of the black hold of table based design 10 years ago was the promise of completely redesigning a site without touching the html. Best demonstrated by the CSS Zen Garden.
Classitis is something I will not budge on. I never have, and probably never will work on a site as large as some of her examples so there’s even less reason for me to switch to a classitic technique.
HOWEVER, classitis is currently the only way that we can have _multiple_inheritance_ of style rules.
Multiple inheritance is a good thing. Classitis is a bad thing. As in it’s bad to have to change your html almost or more often than you need to change your css to achieve a visual change.
What’s really needed is a purely css based method of achieving the same multiple inheritance. It doesn’t look like anyone is thinking about that.
But there are people working on the next best thing: Cascading Attribute Sheets! http://www.xanthir.com/blog/b4K_0
But there’s a big problem there too. Right now it looks like allowing modification of the class attribute is an after thought. It needs to be the primary focus IMHO since that is 1 use case that you, Nicole Sullivan and probably everyone reading this article has experienced a need for.
In theory it sounds so simple, so perfect (not as perfect as having the feature as a part of css itself).
You define all you classes with a classitis / object oriented css state of mind. Then you define your Cascading Attribute Sheets (CAS) file to apply all the classes you need, where you need them, without having to touch your HTML unless absolutely necessary.
To be clear I think she’s 100% correct.
But I feel it would be a big step backwards to sacrifice our ability to get so much styling done without having to touch the html.
We need some kind of inheritance or multiple attributes as a css variable feature within css itself OR the proposed Cascading Attribute Sheets.
I hear you and can understand why you’d rather stay away from adding too many classes. That was my initial feeling too.
The more I looked at it though, the more I realized that under realistic practices we do end up changing our html when changing styles. Not always of course, but for major changes we often need to.
I’ve also thought that it’s not that big of an issue to have some classes in the html. If done well you can rewrite the styles in css and not have to make changes to the html at all. In the worst case you may be left with a class that’s not being used at all in the css. Is that really such a big deal.
Ultimately the goals is to separate structure and style and anything that leads us there is something I want to pay attention to.
Here’s the issue – isn’t design supposed to be separate to content?
Doesn’t oocss mean you are applying design-based classes to your markup, which means they are no longer separate in the true sense? In theory at least, you should be able to alter the design of your pages without having to amend your markup and add or remove a bunch of class names each and every time.
Rather than:
Home
About
I’d much prefer:
Home
About
…even if it does mean writing slightly more convoluted CSS. I’d prefer convoluted CSS over convoluted HTML any day. In my opinion the first example is somewhat like using inline styles or font tags. OK it’s not quite as bad as that but it’s not great either.
In an ideal world the design should revolve around the content and markup, not the other way around.
Hi Gareth. Your code didn’t quite come through, but I think I understand what you were trying to say with it.
My question would be what’s really the difference between setting an element to be an h2 or setting it to be a div with a class=”h2″?
Obviously there’s a semantic difference, but as far as your css concerned the only difference would be a . in front of the h2 when using it as a selector. In either case should you decide to redesign the site you either change the css or decide you want a different html structure and so change that too.
I don’t think more classes means you need more convoluted css or that you have to alter your html to redesign. You can always restyle the css on classes or even ignore them completely in a redesign.
While we all like to say we can redesign solely by changing css files, that’s usually not what happens in practice. I can’t think of a single real project where I redesigned a site without changing both html and css. Sure you can change the color scheme across the site or set up new type, but I don’t think there are many designers who’ve completely redesigned sites, especially if the layout is changing, only through changes in css.