Link to nicer article view on the old Railslove.com (may break any time):
http://railslove-website.herokuapp.com/blog/2012/03/28/smacss-and-sass-the-future-of-stylesheets
title: SMACSS and SASS - The future of stylesheets slug: smacss-and-sass-the-future-of-stylesheets author: jakob_hilden featured_image: http://farm8.staticflickr.com/7261/7731744988_e2c0176b25_z.jpg published: true author_name: jakob author_email: jakob@railslove.com wordpress_id: 1318 wordpress_url: http://blog.railslove.com/?p=1318 published_at: 2012-03-28 18:15:20.000000000 +02:00 categories:
- railslove
- rails
- oss
- css
- sass
tags:
keyword:
- smacss
- sass
- css
- stylesheets
- frontend
- modular
- conventions
UPDATE: We wrote a follow-up to this article titled Taking Sass to the Next Level with SMURF and @extend which you might also be interested in reading.
I just had the the pleasure of attending the SMACSS workshop in Essen by Jonathan Snook (@snookca) and wanted to share my impression of the "SMACSS approach" to CSS and some considerations on using it together with SASS.
On a high level SMACSS aims at changing the way we are turning designs into code (here CSS+HTML). Instead of working in a "page mentality" where you look at a single page's design and try to find the best way of turning that page into code, SMACSS advocates taking a step back and trying to identify repeating visual patterns. Those patterns are then supposed to be codified into flexible modules, which should be as independent as possible from the individual page context. This might not sound so revolutionary from a programmer's point-of-view, but for the web design community this is indeed a new(er) way of thinking. I myself kind of think of it as "data modeling from the other side" instead of trying to structure information (into e.g. a database schema) you are trying to structure visual design into a CSS module architecture. Even for CSS such an approach is not entirely new, but in my opinion SMACSS presents it in a very accessible (=> public website), approachable and pragmatic way. It has many basic ideas in common with the likes of OOCSS, CSS Lint and similar "modular CSS" advocates, but I would say it is less strict and "hardcore" about it. For example, instead of saying "You should never ever use element selectors!", it rather advocates to keep them to a minimum, and still use them where it makes (semantic) sense. The basic concept of SMACSS is to categorize styles into 4* categories: base, layout, modules and states. Each category comes with a set of more ore less loosely defined naming conventions and usage rules. This is where things like CSS resets (if you use them), element defaults (e.g. link colors), default font sizes, etc. belong. The category is largely dominated by element selectors. However, you should always ask yourself "Is this base?" in order to not loose flexibility down the road. This includes all types of layout containers such as header, footer, content, sidebar, etc. The layout elements don't really have any styles of their own, but are simply containers. Obviously, this is the layer where grid systems would be living. All selectors in this category should be prefixed with.layout- (e.g. .layout-header, .layout-sidebar).
The bulk of (SMA)CSS is made up of independent modules and submodules. Examples for modules could be things like: search-box, dialog, navigation, menu, content-box. While submodules are more specific versions of these modules such as: dialog-wide, navigation-tabbed, menu-dropdown.
The ideal module is completely independent of its context and should work within any layout container or other module. If a specific context requires changes to a module you rather create a submodule that describes the context, instead changing styles based on the parent (e.g. .content-box-narrow instead of #sidebar .content-box).
Modules can have different types of states: class-based states (.is-hidden), pseudo-classes (:hover, :focus), attribute states (data-state=transitioning), or @media query states. These states belong right to the modules but have a separate category because they have their own naming convention and usage rules.
I think there are two important things to mention in order to understand where SMACSS is coming from and where it makes most sense. The first is about the role and team setup and the second about the type of product it is designed for.
SMACSS is designed for a "Prototyper" job description, who turns design comps into HTML+CSS, before they are passed on to the engineers. If you have a less rigid, more agile developing process, where maybe one engineer works on both the front- and the backend (e.g. in a startup context), you probably need to cut some corners when implementing SMACSS. Also, the approach is ideally accompanied by a prototyping system/tool, where you create testing templates for each of the defined modules in order to visually test them - both on their own and within other modules and layout containers. Jonathan Snook and his team at Yahoo were using such a custom build system for Yahoo Mail, but something like it yet has to be made publicly available for generic projects. In my opinion this is a very interesting and promising direction to have TDD-like tools for visual testing of frontend code. Looking forward to that!
Secondly, the SMACSS approach was born out of experiences building Yahoo Mail and therefore it makes most sense for web "applications" and not so much for web "sites". The application ideally needs to consist of easily definable modules which are long-lived and appear in different contexts, otherwise creating proper SMACSS modules might just be overhead. The same is probably true, for parts that are a little separate from the application and undergo a lot of design changes, such as landing pages or other ephemeral site areas. Here it might not always make sense to modularize everything.
When I was talking about SMACSS having 4 categories earlier, I actually left out the 5th category which is "theme". I did this because, when using SASS, theming can easily be handled by defining variables for the style properties that you want to be themeable (e.g.$themable-border-color), instead of having to apply special classes to all the themable elements (.theme-border). Here at Railslove we just had to create a new theme (basically a re-branding with different colors) on short notice for our client 9flats.com and we were amazed how quickly we could complete this task on a SASS-based website, which would have taken much longer in "the old days".
The best and most straightforward application of SASS functionality to the SMACSS approach is for submodules. Whenever you need a variation of one of your modules, you are supposed to create a submodule, e.g. .dialog-wide is a submodule of .dialog. While in traditional SMACSS you would need to apply both classes to your element (.dialog
width: 300px
color: blue
.dialog-wide
@extend .dialog
width: 600pxThe only thing you need to be aware of, is to never to extend across modules, which would violate the concept of SMACSS and could easily lead to unwanted side effects.
One thing that I haven't quite made up my mind about is the syntax within modules. SMACSS proposes that every component within a module should have a) its own selector (for performance) and b) be prefixed with the module name (for clarity). Like this:.dialog
width: 500px
.dialog-header
font-weight: bold
.dialog-body
font-size: 13pxThis syntax is in some conflict with the way I have gotten used to authoring stylesheets with SASS, making heavy (sometimes too heavy) use of its nesting capabilities & syntax. Using my traditional SASS style, it would probably look something like this:
.dialog
width: 500px
.header
font-weight: bold
.body
font-size: 13pxI feel that all the prefixing adds a lot of distracting verbosity to the stylesheet and by nesting all the components underneath the module selector it actually gives it a nice visual closure. The important requirement here is that you keep the component number and nesting depth of your module to a minimum. But I think in this case applying the modular SMACSS philosophy is actually one of the best things that could happen to SASS, because the best practice to minimize your nesting has been pushed too little and therefore been overlooked far too often by SASS practitioners. However, the big downside with this approach is that you loose a lot of clarity in the markup, because now it's not obvious anymore to which module a component class such as .header belongs to. One idea to alleviate this problem could be to have a more obvious naming convention for module selectors (e.g. .module-dialog), so it's easier to trace your way up in the markup from a component class to the next module selector it belongs to.
The other more minor downside of nesting would be the loss in CSS performance due to longer selectors caused by nesting. However, unless you are not working on a super high performance website with massive reflows, lots of old browsers and complex mobile requirements, most sources [1, 2, 3, 4] make me believe that heavily optimizing for CSS performance, isn't really worth the effort, especially in a startup environment.
So, if we say that, on the one side we don't care so much about CSS performance and we do like the visual clarity of SASS nesting, but on the other side we also like the idea of always knowing which components belong to each other based on prefixes, a syntax like this could actually be a compromise:
.dialog
width: 500px
.dialog-header
font-weight: bold
.dialog-body
font-size: 13pxIf you then should start to worry about performance at some point you can easily convert to pure SMACSS. However, I myself am not really sure yet what syntax I really prefer. What do you think?
File structure
SMACSS already includes quite sensible naming conventions for selectors, but coming from the Rails/SASS world we obviously also value conventions for our file structure. My suggestion for a SMACSS+SASS file structure would probably look something like this:
+ applications.sass // @imports
+ base/
| _settings.css.sass // SASS config variables
| _reset.css.sass
| _colors.css.sass
| _fonts.css.sass
| _element_defaults.css.sass
| _form_defaults.css.sas
+ layout/
| _settings.css.sass // SASS layout/grid variables
| _containers.css.sass
+ modules/
+ non-modular/
I guess there is nothing too surprising in there. The only thing that I would add is the folder/area for non-modular styles. As I said earlier there are always cases for pages/styles that are not very long-lived, not "fully baked", and so on. Those should go to the non-modular folder. Here it probably also makes sense to write highly specific (maybe even controller/view-specific) styles. With that I would just want to prevent any half-assed styling attempts to bleed into the modular styles. If styles in there last longer than expected, you can always go back and "graduate" them to proper SMACSS modules.
Concerning file structure there is a little shell script by Wynn Netherland to create a (much simpler) SMACSS folder structure for SASS, maybe this could be extended for further integration between the two.
The last little thing I want to talk about is a small issue I have with the SMACSS syntax and that is the indifference between the syntax for submodules vs. module components. If you have for example a selector such as.navigation-header, this could either be a submodule of the .navigation module (submoduled for the header context), or it could be a component of the .navigation module assigned to the header element of the navigation. It's not a big issue, but I nevertheless think it would be valuable to be able to discriminate the two on first sight. Jonathan mentioned that a suggestion for differentiation, that was brought up, was to use two -- vs. one - dashes, e.g. .navigation--header (I think for the component) vs. .navigation-header (for the submodule). Not sure that this is the ideal solution, but I truly think that it would be very good being able to differentiate them.
SMACSS is a very user-friendly approach to modular CSS. It asks for nothing less than a complete shift from a "page mentality" towards webdesign, to a search and codification of visual patterns. For that it offers a concise and sensible categorization and naming scheme.
It generally goes along very well with SASS, especially using the @extend feature and when it comes to themeing. It's kind of an open question how SASS's nesting capabilities fit with SMACSS, but in general I think it can bring lots of very valuable and badly needed modularity and conventions to the SASS/Rails community.
UPDATE: We wrote a follow-up to this article titled Taking Sass to the Next Level with SMURF and @extend which you might also be interested in reading.