We need to talk about your stylesheets: An interview with Jonathan Snook at Drupalcon Portland
By
ivan3 min read
Share on:
Summary
A Q&A with the author of SMACSS, or Scalable and Modular Architecture for CSS: Jonathan Snook, a featured speaker at Drupalcon Portland.
This is an intervention.
CSS is pretty simple. Classes, IDs, elements and pseudo-elements, with style
definitions attached to each. Calling it a “language” is a bit of a stretch
(though preprocessors like Sass fit the bill).
But let’s be honest, for years our stylesheets cascaded right on out to
infinity.
Huge files with table-of-contents comments to try to make some sense of it –
until a quick fix got pasted down at the bottom. Brittle style definitions
relying on tight coupling with HTML structure. Pieces of styles being replicated
here and there for different components with similar features, without any way
to tell they were related in the CSS.
My stylesheets were like that too, because strategies for writing CSS had barely
altered since the days when it was used to change the colors of the scroll bars
in Internet Explorer. Luckily, in the past couple of years both
CSS architecture and CSS preprocessors came into their own.
SMACSS, or
Scalable and Modular Architecture for CSS, was developed
by Jonathan Snook, a featured speaker at Drupalcon
Portland. I’m really excited to get the opportunity to have Jonathan speak, not
only because of my personally well-dog-eared copy of SMACSS, but because
Drupal itself is
adopting a SMACSS approach
to its CSS.
IB: What’s the biggest mistake you see people making when writing CSS?
JS: I think the biggest mistake is thinking of everything in the context of a
single page. We’re no longer just building sites with a design for a home page
and an inside page. We’re developing complex systems that need to work in a
variety of contexts and we need a development approach that complements that.
IB: What’s
the biggest “win” you see in using the SMACSS approach? Why should frontend
developers change their approach to CSS?
JS: The biggest win is maintainability. The SMACSS methodology makes it easier
to build larger projects by breaking things down into smaller components. Like
the move from spaghetti code to
MVC
frameworks on the server side, this separation of concerns on the CSS side
improves the process of putting a site or web app together.
IB: In the last part of your book, you talk about how the SMACSS approach fits
in to work using a preprocessor like Sass. There have been a lot of developments
in Sass in the past year – have they had any positive effects on your use of
the SMACSS approach?
JS: With Sass, the introduction of placeholders was a positive step forward.
Overall, Sass (and other preprocessors) are a great way to augment – but not
replace – the way people write CSS.
IB: What are your thoughts on BEM? Do you see it as
compatible with SMACSS?
JS: I see BEM as very compatible. BEM really enforces naming convention, which
is a very important concept in SMACSS. They both take a modular approach to site
development.
IB: What are you tacking next when it comes to CSS and frontend development?
Will there be a “SMACSS Part Two”? Or something else entirely?
JS: I’d love to augment SMACSS with case studies and expand on some of the ideas
in the book based on things that come up in the workshops I do. I’d also like to
work on a prototyping/site development tool that uses the SMACSS concepts. We
had built something like this when I was at Yahoo! that I think many people in
the industry would find really useful. Hopefully I can find the time to work on
it!