Hiya,
About three weeks ago, @fat, known for his part in developing Twitter Bootstrap, posted an article on Medium which outlined his experiences with writing flexible, maintainable CSS. This article resonated with me. My application, while visually appealing, did not have much rhyme or rhythm to its CSS. I wanted to do better and his writings provided me with a foundation.
Over the course of the last week I put about 70 hours into refactoring. I am very pleased with the result and wanted to share. Undoubtedly there are more improvements to be made, feel free to critique, but I can't say enough about how nice it is to finally have a structured layout.
Some background on the project:
- The software is for playing music and containing playlists of songs; 130K weekly users
- Here is an album of screenshots of the UI
- Originally 1500 lines of LESS in a single file
- Now 44 lines
- 31 modules. Each module relates to a component's namespace
Implementing @fat's suggestions was incredibly fun. I'd like to address all of the topics he brings up in his article and talk a bit about them point by point. For reference, here is the guideline I am discussing
JavaScript
Not much to be said here. This is a very sane idea which I implemented throughout without complaint.
Utilities
I came up with a reasonable set of utility classes for my application which can be seen here. My biggest concern was going too crazy on adding utility classes. It was very common for me to create a utility class, apply it, and then realize the applying areas all share common traits. This results in a new component type being created and the utility class being removed.
You'll note that I have not prefixed two classes in this file. I encountered an issue with @fat's naming conventions. Classes which felt like utility because they did not need per-component customization, but could also be affected by JavaScript. I am still unsure if the proper prefix is .is-, .u-, or if the code itself is bad and should be reworked.
Components
This was the best part of the whole thing. "--" for modifier names and "-" for descendants made a lot of sense to me. I noticed a non-trivial speed increase in my application's performance by reducing the nesting in favor of namespaced components. I did have a couple of concerns while implementing components. For instance, some of my use cases required a wrapper div. I ended up using the "descendant" namespacing for these wrappers, but I suspect that's not strictly adhering to his guide. Additionally, I was a bit more flexible on my is-stateOfComponent usage. While I understand the reasoning behind not styling the stateful class directly I believe that this was being a bit strict. Sometimes you want a stateful class which affects multiple types of components.
Variables
I didn't strictly follow this suggestion, but I might go back through and take a stab at it. I scope variables very closely to where they are used to avoid confusing, but I'm sure a namespace would be beneficial, as well.
Colors
I wish @fat had provided a reasoning for preferring RGBA over hex. I use hex for my colors and am happy with it. I think consistentcy is the key point here.
Z-Index
I went into this rewrite fully anticipating to generate a bevvy of useful z-index scales. I used z-index a fair bit throughout my LESS. Surprisingly, after all the dust had settled, I only had need for "z-index: 1" on two components. I decided a simple utility class, '.u-aboveContent', would suffice.
Font Weight / Light Height
I created fontSize and lineHeight scales in the same vein as the ones shown in the guide. These were very beneficial. I was forced to use a strict subset of sizes which led to a UI which felt more consistent.
Polyfills
I don't have much of a need for polyfills because my application is only used on Google Chrome. However, I disagreed with @fat's decision to completely ban the use of mixins aside from polyfills. I think mixins are a powerful language feature which can help create reusable, consistent code. My only complaint is that it is unclear when to use a mixin on a class in LESS versus applying it as a class on a DOM element. I still don't have a good answer for that and perhaps that is why he implemented stricter policies on their usage.
Formatting
I agree with all of his formatting choices for the most part. I prefer a little extra spacing between my classes, but everything else I'm on board with.
Performance
This was a big one for me. I tore through my entire application trying to get better performance out of my CSS -- and with good success! I had gone crazy with my nesting, thinking it was more OOP, but now realize that thought was misguided. Making reusable components with limited nesting has many benefits. Giving elements thoughtful classes instead of applying CSS directly to specific types of DOM elements removes a lot of confusion, improves re-usability, and also improves performance. Awesome!
Overall, @fat's guide was the best thing that ever happened to my CSS. He knows what he's talking about, but could have provided more reasoning behind the madness in some instances. Hopefully my changes will allow for more rapid development of a consistent layout in the future. :)
Nice write up of your experiences!