Applying these principals to new projects was the next challenge. First we need to be better at decomposing our designs. The inside-out approach is key to this process, the goal of the file structure, and necessary for a scalable architecture. Simply put, code the element, create the module and assemble the layout.
At this point you may be drawing parallels with Jonathan Snook's SMACSS approach, as you should. The approach I adopted shares many similarities that were later outlined in Jonathan's book. But alas, there are differences due to the vary nature of Sass and the additional features that it supports over vanilla CSS.
While many of these concepts are solid ways to architect a scalable CSS structure, they are somewhat constrained by the limitations of vanilla CSS. But this is a book about Sass and we are not as easily constrained by these limitations.
In SMCASS, there are five types of style categories:
Core styles that will make up your site or application. Base rules are commonly applied to an element using the element selector itself. Thrown into this bucket would be the CSS reset, typography, forms and buttons. These base styles will each have their own Sass file for easy management, here is an example from a _typography.scss Sass file.
html {
font: em($font_size, 16) $primary_font_family;
line-height: baseline($font_size);
color: $primary_text
}
// Heading CSS rules
// --------------------------------------------
h1, h2, h3, h4, h5, h6 {
@include heading();
}
// Standard body text support
// ---------------------------------------------
p {
margin-bottom: baseline-margin($font_size);
text-indent: 0;
}
a {
color: $href_color;
text-decoration: none;
&:hover, &:active {
text-decoration: underline;
}
&:visited {
color: $href_color;
}
}
SMACSS and I share a similar point of view. Consider modules as 'nouns' in your code. These are the 'things' that you will be making the most use of. Leveraging the styles created in base, I can begin to create small and large modules that can be infinitely reused.
Where Sass begins to add super powers is it's ability to break down modules even further into infinitely more reusable code. The use of mixins and placeholder selectors strike an even more amazing balance between presentational selectors in your CSS and semantic selectors in your markup.
State is a powerful concept and again fully supported. State typically is an over-ride to the default style placed on an element or module. If the module is a noun, then the state is the module's verb. Common concepts are .is-hidden or .is-error.
Where I slightly differ with Sass is I feel that state rules are better managed within the parent selector versus always having completely separate rules. This is not a fundamental change in the state concept, but an area where Sass shines a light on the limitations of vanilla CSS.
SMACSS emphasizes using the !important tag when creating stand alone selectors. I find this approach to be somewhat problematic. Instead, I advocate for not only creating a standalone default rule for the management of state, but in the cases where specificity is needed, nesting the state rule in the module it is designed to augment is preferred.
In regards to layout, I take a different approach all together. SMACSS considers layout as slightly different representation of the module, conceptualizing them as major page components. Examples would be .site-header, .site-footer and .main-nav.
I on the other hand, as discussed further in this chapter, consider layout to be a more holistic assembly of a view or template for modules to be inserted. I consider the layout to be the structural CSS that comprises the grid in various states depending on user input and environment. To me, the layout is the key to easily manage responsive web designs as so may of the UI decisions are based on the layout, not the module themselves.
Much like layout, I take a completely different approach all together. Sass' ability to create UI variables, mixins and placeholder selectors allows me to re-write the concept of CSS theming. In SMACSS theme is not considered part of the core types, where I see it as an essential player on the construction of the site design.
A good example of a theming solution would be with a tool-tip bubble. For example the tool-tip module would consist of inheriting typography, applying some shape and aesthetics such as a carrot. The theme of the tool-tip would be it's padding, color, border and possibly a shadow effect. With vanilla CSS, it is recommended that you engineer the module itself, then later in a "theme" section of your CSS you again reference the selector to add it's theme rules.
With Sass we can take this to a whole new level by engineering the tool-tip as a self contained module either as a mixin that accepts arguments or a placeholder selector with variables. Selectively enhancing the module at the time of placement and coupled with the concept of a _config.scss file, I can list out all the configurable "theming" parts of the site's design.