For a while now I have been considering the formatting of sass files to maximise their usability by other coders and I think that this would be perfect place to get some feedback on the rules I try to apply when writing a sass file. I am specifically interested in the usability of the source code as it is created and maintained by humans, as well as with the correct creation of css code. Some of these rules could be applied to sass or vanilla css.
The rules I have been honing are as follows:
-
Start general and get specific. So start with body font size, colour variables, default tag declarations etc. then move through the parts of your site that are common to all pages, then onto the re-usable elements on the site and finally concluding with page specific styles, with the liklihood of cascading re-use and the potential for over-ridden styles increasing as you move through the document(s)
-
Try to group selectors in a way that matches the distribution of html amongst views. So if I look at widget.view the file or block of a file labeled widget.scss will contain those styles. NB, I specifically do not mean following html sructure with hierarchical sass in this case.
-
Following on from that. Minimise the amount of hierarchy defined in sass. Only use sassy {} based inheritence when needed.
-
Group properties into logical sets, so width and height together, font declarations together, rather than everything alphabetically.
-
Always consider the resulting css file size and be prepared to use classes if necessary instead of mixins, editor snippets or other bloat encourgaing techniques.
-
Put more than one property per line in certain cases, following on from the logical grouping of elements, meaning more code can be fitted onto a monitor screen without going so far as to make lines too long to read easily. No more than 3/4 properties per line.
-
Block code in files by indenting all selectors after an introductory comment to make the the left hand side of the file easy to scan and to quickly discover it’s contents. Also provide a file map of these blocks at the top of the file if it is large.
-
Use placemarkers for find operations, such as ^NAVIGATION
-
Only use classes for styles. And don’t be afraid to use classes for specifcity and to make re-use more atomic. [edit for clarity – I don’t mean use only classes, I mean use classes instead of IDs]
-
Use a completely separate set of javascript specific classes for binding functionality to html elements, meaning that either form or function can be swapped out without damaging the other. These classes are not refered to in the css.
-
Selectors one per line and in alphabetical order as they are arbitrary in name
0
Most of your points are very obvious and make sense no matter what type of project you’re working on. Speaking from a Sass standpoint, rather than a pure CSS standpoint, some of them make very little sense.
#5 (consider the resulting css file size)
This is a major point that most people don’t quite grasp when it comes to using @extend in Sass. If your mixin is generating a lot of code that can be shared with other selectors, then @extend is a good idea. If you have lengthy selectors or the code being shared is rather short, using @extend is going to lead to a larger CSS file (see: https://codereview.stackexchange.com/questions/26003/mixin-extend-or-silent-class/27910#27910)
#6 (more than one property per line)
This is purely a style preference and has no impact on the code’s performance or reusability. In my opinion, this only reduces readability of the source. The generated CSS is going to be formatted according to the chosen output style, so the format of the source is irrelevant (unless you’re using SASS syntax where whitespace/indentation matters).
Some of this applies to some of your other formatting specific points, too.
#9 (Only use classes for styles)
If your goal is to be reusable, then you should never use classes. One of the more commonly asked questions regarding libraries like Bootstrap are “how do I use X with only semantic names” or “how do I get the code for X from this module without also importing the code for Y”. Instead, make good mixins and functions so that users can compose them in ways that make sense for their project.
#10 (separate set of javascript specific classes)
Form follows function. If what you’ve got is a toggle, then there is a difference in styling between the opened and closed states. It does not make sense to make another class just for that.
There are other properties worth considering which may make more sense (both from the JavaScript and CSS side) such as disabled, checked or the use of data-* attributes (eg. data-state="opened").
2