I wanted to discuss each a little and more importantly point you to
both in case you haven’t seen them. Some of you have also provided even
more for me to take in on the subject and I promise I’ll get to those
links as soon as I can.
Andy’s presentation, CSS For Grownups: Maturing Best Practices, (found via Jeremy Keith) builds on the work of Nicole Sullivan with OOCSS and Jonathan Snook with SMACSS.
His talk mainly looks at moving from current descendent selector practice toward a more modular class based approach.
Nicolas’ article, About HTML semantics and front-end architecture, is more focused on html semantics and dispels the notion that all these class names are unsemantic. If you’re struggling a little to move toward classes due to worries about making your html less semantic I think his post will convince you that you don’t need to be worried.
This gets masked at times if you only work on smaller sites. With fewer instances of difficult to maintain code, you can usually overcome the maintenance problems with a little extra effort, but the issues are still there.
Even if you don’t currently work on large sites or plan to, you should still rethink best practices and improve your systems. Small sites grow larger. Personal goals change. New technologies and techniques spring up all the time and we should be prepared.
The main ideas behind all this rethinking of best practices is
At first glance it seems like adding classes to html increases coupling due to the added markup, but the opposite is actually true. Coupling is increased the more dependent we are on a specific html structure. Jonathan Snook referred to this as the depth of applicability. The greater this depth, the greater our html and css are coupled.
Unfortunately our best practices the last few years have been increasing coupling even as we thought we were decreasing it.
Compare the images from Andy’s slides above this section and just below. In both the css is simple. It’s adding a background image to each of three different social buttons. In the slide above the selectors take the form .social li:nth-child(x).
When this nth-child selector is used, structure and style are highly coupled. Changing the order of the html so the Facebook button comes before the Twitter button requires a similar change in the css.
On the other hand the slide below shows similar css, except the nth-child selector has been replaced by a class in the form .social .twitter. This requires that extra code (the new class) be added to the html, but now you can rearrange the order of the buttons in the html without having to make any changes to the css. There’s less dependence on the specific html structure.
Later in the presentation Andy talks about different layers of css. He offers 4 in his example without suggesting these are the only 4.
The two blocks in the middle tie things to the html structure by
including the hx tags. You can imagine how this can quickly get out of
hand as you add more headings or other elements. The combination of the
first and last blocks of css above are best. Each affects only one layer of the css, in this case the module layer, and it makes the resulting css much more manageable.
Andy continues with an example of headings alone. I’ll let you check the presentation and slides for the details, but the gist is he transforms the typical hx styling we do to a class based approach.
He walks through lists in a similar fashion moving the css from ul.product-list li to .product-list li to .product-item.
Nicolas’ article focuses on class semantics. He says there are different types of semantics. We tend to think content driven semantics when talk about the subject, but there are also agreed upon global semantics such as microdata.
He makes 4 points about semantics.
The above class name is a bad choice because it adds no additional
meaning we couldn’t get from the content itself. It also ties the class
name to the content and so can’t change easily. For example it wouldn’t
make sense to present recent comments inside of a div with a class name
of news.
Once again coupling has been increased, reducing scale and maintainability.
Our goal should be to develop reusable components that can contain a range of content types. The most reusable components are those with class names independent of the content they hold. Nicolas talks further about how we can make css components more reusable and combinable.
It’s definitely worth a read.
We’ve been making our html, css, and even javascript less maintainable for years. We’re used to it and have found ways to work around the problem or we work mainly on sites small enough to hide some of the issues, but those issues are there nonetheless.
Andy’s presentation, CSS For Grownups: Maturing Best Practices, (found via Jeremy Keith) builds on the work of Nicole Sullivan with OOCSS and Jonathan Snook with SMACSS.
His talk mainly looks at moving from current descendent selector practice toward a more modular class based approach.
Nicolas’ article, About HTML semantics and front-end architecture, is more focused on html semantics and dispels the notion that all these class names are unsemantic. If you’re struggling a little to move toward classes due to worries about making your html less semantic I think his post will convince you that you don’t need to be worried.
Why Rethink CSS Best Practices?
It’s relatively simple to learn the syntax and basic use of css. What’s not so simple is to create scalable and maintainable css systems. Many of the best practices we’ve developed over the years aren’t helping. If anything they’re leading us to develop less scalable and maintainable stylesheets.This gets masked at times if you only work on smaller sites. With fewer instances of difficult to maintain code, you can usually overcome the maintenance problems with a little extra effort, but the issues are still there.
Even if you don’t currently work on large sites or plan to, you should still rethink best practices and improve your systems. Small sites grow larger. Personal goals change. New technologies and techniques spring up all the time and we should be prepared.
The main ideas behind all this rethinking of best practices is
- To create us more maintainable css
- To help our css coding practices scale
Decoupling HTML and CSS
Andy’s talk was in part about how we can uncouple css from html so our styles are less dependent on our structure. Less coupling leads to a more maintainable site.At first glance it seems like adding classes to html increases coupling due to the added markup, but the opposite is actually true. Coupling is increased the more dependent we are on a specific html structure. Jonathan Snook referred to this as the depth of applicability. The greater this depth, the greater our html and css are coupled.
Unfortunately our best practices the last few years have been increasing coupling even as we thought we were decreasing it.
Compare the images from Andy’s slides above this section and just below. In both the css is simple. It’s adding a background image to each of three different social buttons. In the slide above the selectors take the form .social li:nth-child(x).
When this nth-child selector is used, structure and style are highly coupled. Changing the order of the html so the Facebook button comes before the Twitter button requires a similar change in the css.
On the other hand the slide below shows similar css, except the nth-child selector has been replaced by a class in the form .social .twitter. This requires that extra code (the new class) be added to the html, but now you can rearrange the order of the buttons in the html without having to make any changes to the css. There’s less dependence on the specific html structure.
Later in the presentation Andy talks about different layers of css. He offers 4 in his example without suggesting these are the only 4.
- Document
- Base
- Module
- Layout
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
.promo-box {
color:red;
background: black;
} /* module only */
.promo-box h3 {
font-size:1.2em;
text-transform: uppercase
} /* module and document collide */
.promo-box h3,
.promo-box h4 {
font-size:1.2em;
text-transform: uppercase
} /* continuing to add more document collisions */
.promo-box .promo-box-h {
font-size:1.2em;
text-transform: uppercase
} /* module only with the second class expanding on the first */
|
Andy continues with an example of headings alone. I’ll let you check the presentation and slides for the details, but the gist is he transforms the typical hx styling we do to a class based approach.
1 2 3 |
h1 { font-size: 3.0em; } /* initial hx selector */
.h1 { font-size: 3.0em; } /* changed to a class named after the hx tag */
.h-headline { font-size: 3.0em; } /* changed to a class name that better describes it's purpose in the design */
|
Semantics and Class Names
One of the best practices the industry is trying to change is to avoid classitis at all costs. We’ve been taught that classes are unsemantic and we should add as few as we have to. This isn’t true.Nicolas’ article focuses on class semantics. He says there are different types of semantics. We tend to think content driven semantics when talk about the subject, but there are also agreed upon global semantics such as microdata.
He makes 4 points about semantics.
- Content-layer semantics are served by html elements and attributes
- Class names impart little semantic information outside of agreed upon standards
- The primary purpose of a class name is a hook for css or javascript
- Class names should communicate useful information to developers
1 2 3 4 |
<div class="news">
<h2>News</h2>
news content
</div>
|
Once again coupling has been increased, reducing scale and maintainability.
Our goal should be to develop reusable components that can contain a range of content types. The most reusable components are those with class names independent of the content they hold. Nicolas talks further about how we can make css components more reusable and combinable.
- Javascript specific class names — (js- prefix) can help reduce the risk that changes break Javascript
- Single-class css pattern — styles get defined on multiple classes so only one class is needs to be added to the html
- Multi-class css pattern — styles kept more modular and multiple classes are applied to the html (preferred approach)
- Structured class names — naming patterns to make presentational relationships more understandable
It’s definitely worth a read.
Summary
Most of us have been following the same set of best practices for years. I certainly have. Unfortunately many of those practices were based on incorrect assumptions about coupling and semantics.We’ve been making our html, css, and even javascript less maintainable for years. We’re used to it and have found ways to work around the problem or we work mainly on sites small enough to hide some of the issues, but those issues are there nonetheless.
No comments:
Post a Comment