Things To Avoid When Writing CSS
Heydon
70560

Okay, so the multiple files thing seems pretty unpopular. I figured it would probably be the most controversial, which is why I got it out of the way at the start.

To clarify, I am aware that Sass allows you to @import in a way that both compiles the result automatically (neat) and which can be done in the order of inheritance (_reset.scss, first for example).

My problem is with working in fragmented files in the file system; files which are listed out of inheritance/cascade order. I find it personally difficult to “see the wood for the trees” this way because I write CSS that doesn’t try to strictly deal in objects. In any case, inheritance happens and I’ve experienced front end teams struggling when one file is edited by one dev which has implications for another file.

A CSS file that contains all the CSS is an easier thing to review, because you see the whole picture. If I were to receive a pull request for a CSS partial, it would be considerably more difficult for me to judge its veracity. “Where does this fit in?” “What does it inherit from?” “Is it too specific too early?” “Have these styles been catered for already, in another form?” It’s not impossible to answer these questions between multiple files but it involves a lot of flitting about. I’d sooner look at “the CSS” and diff that.

Additionally, I don’t think that any application should be so complex that it needs any more than about 60Kb of CSS. If much more than that is needed to realize the intended interface, then I put it to you that the interface itself is an overly convoluted and contrary shit show. This happens a lot and it’s more a design and stakeholder management issue than an engineering / facilitation one, but there you have it.

Results for you may vary, of course, and I’ve read your reasoning with interest.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.