My project this week has been a refactoring of a massive CSS file, which has to override a mountain of inherited garbage in a CMS that can’t be touched. More precisely, something like 3000 lines of CSS in no less than seven stylesheets are coming at every page and I’m cleaning up nearly two thousand more lines of code that are inline overrides. On every page.
Where to start?
Can’t change any of the source of the page, nor anything in the inherited stylesheets. So that means rolling with inheriting things like #id > .class .class:hover and just having to fight fire with fire. It’s a great puzzle, no? Did I mention that this definitely hits the invisible walls with IE of maxiumum number of declarations?
While thinking this through, the most radical approach I considered was this: taking every selector that, for example, sets a margin to zero and making a mega comma-delimited list of those. Doing CSS backwards. Making lists of selectors for each and every style. I dismissed that idea, for now, but want to try doing something awful like that. for fun.
What I did was this: I pasted all those inherited stylesheets into a single .SCSS stylesheet. (Did I mention they’re all formatted and minimized differently?) And then I made a .SCSS file with the whole of the inline styles I can refactor and included the inherited .SCSS — in the compiled output CSS file, I could at least start to search the whole thing to figure out what the overrides were actually overriding, and whether they were at all redundant.
Another big benefit to doing this as SCSS instead of CSS was the two types of commenting: /* ... */ (which carries through to the compiled CSS) and // ... (which doesn’t) — being able to make internal notes about what might be changed before making those changes.
In that first major file, it looked like the earlier styles were mostly redeclaring basic resets and resetting some custom formatting classes (.n3, .n3, .n5 ??), so I pulled those out into their own 1-KNOCKOUTS.SCSS file and included that with SASS.
Geologically speaking, it also looked like the big stylesheet had two major chunks of work followed by a bunch of small patches. I pulled those three areas into their own .SCSS files which left my main .SCSS file with five includes and a bunch of visual commenting blocks to separate them: 0-INHERITED, 1-KNOCKOUT, 2-INITIAL-LAYOUT, 3-LAYOUT-UPDATES, 4-SPECIAL-FIXES.
Something like:
/**********************************************/
/* 0. INHERITED STYLES FROM CMS */
/**********************************************/
@import "0-INHERITED";
/**/
/ 1. KNOCKOUT STYLES TO OVERRIDE INHERITED /
/**/
@import "1-KNOCKOUT";
Doing a CSS Lint, I found some bugs in the inherited styles, so I made corrections as new declarations in the 1-KNOCKOUT file, before the resets and overrides. For example, if a semi-colon had been missing on a .class { font-weight: 7px border: none; } then I added a .class { font-weight: 7px; border: none; } chunk before the html,body {} part of the reset, just to be safe. Also it frankly felt good to spike the ball on some inherited bugs.
Anyway, with those SCSS containers, I bulked up the visual style of the comments in 2- & 3- and made them more consistent, combining the two into one 2-LAYOUT.SCSS file. How? By changing the SASS compilation format from “Expanded” to “Compact” it was much easier to see the /* ... */ formatted comments and decide on a style that was legible: lines of dashes above and below breadcrumbs that explain what types of modules the styles modify. Fortunately the author of the styles to be refactored left solid comments and organized the files well.
For the later 4-SPECIAL-FIXES file, I first looked in the project history for the bugs they were addressing and the test pages. I added those test pages with //-style comments like
// cf: /section/page123Then, I looked for places they could be better folded into the LAYOUT styles, swapping in the new styles and testing on the test pages. Given the options, I was surprised to find so much benefit from cleaning up the overall formatting and commenting, but the code feels more approachable and more likely that subsequent patches will be added in the upper-middle of the stylesheet instead of tacked on at the end.
CSS is, for real, my favorite fun.