I subscribe to the Treehouse newsletter, so should you, there’s always a link to something worth clicking. One such post this week was mostly about CSS performance, check it out here. A section that caught my eye was about “Complex, Overqualified Selectors”, for example:
.wrapper .main .post a {...}
This got me thinking about SASS, and how it outputs CSS. Quite honestly, I never even look at the compiled CSS these days. But heavy use of @extend and nesting looks like it could slow the site down as SASS may output a long list of selectors and elements.
Yeah, but CSS is fast
Firstly, I think this is a micro-optimisation topic. CSS is interpreted super fast, and although it is important to keep it as concise as possible, I think streamlined workflow trumps compiled output. However, I’m going to think more about use of extend and nesting.
I think for @extend, I’ll keep it to clearfixes and other global utilitarian styles, to be fair I don’t use it very often anyway. And nesting, which I love and is super powerful for modular sites, I may keep to one selector deep.
An extreme example of the heavy way:
.sidebar { ...styles... .someWidget { ...styles... h4 { ...styles... a:link, a:visited,{ ...styles... }//a }//h4 }//someWidget }//sidebar
The link styles would output to this, which is pretty obnoxious:
.sidebar .someWidget h4 a:link, .sidebar .someWidget h4 .a:link {...styles...}
The lighter way:
.sidebar { ...styles... .someWidget { ...styles... } h4 { ...styles... } a { ...styles... } a:visited { ...styles... } }//sidebar
Which means the links would compile to:
.sidebar a, .sidebar a:visited{...styles...}
Much better, and less “expensive” so browsers don’t have to parse too many selectors, but maintains the modular benefits of nesting. Everyone’s a winner.
Comments