I’ve been using CSS for 15 years now.  I’ve used it in it’s most basic form and through pre-processors like LESS and SASS/SCSS, manipulated it through JavaScript, and most recently tried out Stylus. Like most people who have been using a technology for a long time, I feel like I can solve any issue that is thrown at me, but I’ve come to rely on the same patterns to approach layout, even as new capabilities emerged. Recently I’ve been plowing through the Treehouse CSS courses. I find that for every 4o things I already know, I’m learning one new thing, and it’s making me completely reevaluate how I’ve approached layout.

I’ve been refactoring the entire SCSS stylesheet codebase at work, which has not been a protected resource. I’m using sass-lint to handle the systematic chore of correcting naming conventions, whitespace discrepancies, and discouraged practices. I’m finding convoluted overrides and nesting as deep as 7 levels where a more complete knowledge of CSS capabilities could have avoided these pitfalls.

When I first ran sass-lint against our stylesheets, it came up with 9625 errors.  I’ve whittled that down to 243, but more important than coming up with 0 errors at the end, I’d like knock down the total line count with more powerful use of CSS3.  I didn’t say more powerful use of SCSS, because that’s a given, but I stay aware of the output, solving layout in the best way possible at that level. The biggest offender of the set was a stylesheet for a specific feature with a line count of 3558 lines; 1000 of those lines were global styles. Why this one developer chose to write 1000 lines of global styles within a feature stylesheet will remain a mystery to me, as he has long since moved on. Many of the styles were not even utilized, reiterated global styles set in an appropriate file, or were overridden by other classes.  Because of it’s cascading nature, CSS is more difficult to debug in this sense than classic programming languages are.

Sometimes I come across code I’ve written, and while most of it is still acceptable in my eyes (named properly, focused, avoiding levels of override), I have removed some of the complexity simply to try out what I’ve learned, and reduced the line count as a result.

This project has been tedious. Every class I come across, I search the app code for usage, find the usage, view it in the Chrome, inspect the class tree in Developer Tools, and make a decision that falls within a loosely held paradigm in my mind and complies with scss-lint rules, and then review in the browser to make sure, stylistically, I changed nothing. Thus I can say my eyes have been on every inch of this layout code. Luckily it isn’t my sole responsibility, but the way I’ve broken it up by segment gives me nice little successes along the way and I’m looking forward to the end result positively effecting build time and front end developer on-boarding. Just to be thorough, I am working on a new version of the visual style guide as well, which ties the classnames to wireframes by way of matching naming convention to UX Patterns.