organise Less files into directories:
base/
normalise.less
base.less
layout/
grid.less
layout.less (or one file per layout if required)
(keep media query variations within the layout file)
module/
one file per module (and any sub modules)
(keep media query variations within the module file)
state/
state.less
(haven't found a use for theme/ yet)
css.less
for the stuff that doesn't fit directories above
style.less compiles into the drupal themes style.css
define constants (or perhaps put constants in it's own less file)
import all the less files
.l-name
never have gutters attached to grid areas (e.g. columns), add padding directly to the units (i.e. blocks / nodes) that are placed into the grid areas
.module-name
.module-name--head
.module-name--body
.module-name--feature
.module-name {}
.module-name--head {}
.module-name--body {}
.module-name--feature {}
use subclassing to avoid specificity, and instead of reworking classes for different class/id contexts
.module-name .module-name__sub-class
.module-name--head
.module-name--body
.module-name--feature
.module-name,
.module-name__sub-class {}
.module-name__sub-class {}
.module-name__sub-class .module-name--head {}
.module-name__sub-class .module-name--body {}
.module-name__sub-class .module-name--feature {}
.things
.thing
.thing
.is-active
- Box
- position
- display
- clear
- float
- left, top, bottom, right
- width, height
- margin
- padding
- Border
- Background
- Text
- color
- font-size
- line-height
- Other
- aim for a low depth of applicability (distance between dom tree ancestors/descendent)
- it causes dependence on html structure and makes components harder to move around
- don't nest too deeply
- prefer classes as selectors over dom elements
- speed: css is parsed from right to left
- decoupling: you might want to change the choice of element
- when a visual treatment is added to several classes (perhaps as a mixin) consider creating a new class