https://github.com/jdsteinbach/boilerplate-sass

Some boilerplate Sass partials
https://github.com/jdsteinbach/boilerplate-sass

Last synced: 9 days ago
JSON representation

Some boilerplate Sass partials

• Host: GitHub
• URL: https://github.com/jdsteinbach/boilerplate-sass
• Owner: jdsteinbach
• Created: 2014-09-17T19:40:33.000Z (about 10 years ago)
• Default Branch: master
• Last Pushed: 2018-02-12T16:21:50.000Z (over 6 years ago)
• Last Synced: 2024-10-07T21:03:04.151Z (about 1 month ago)
• Language: CSS
• Homepage:
• Size: 119 KB
• Stars: 4
• Watchers: 3
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

README

        
# Sass

The repo [README.md](README.md) contains instructions from compiling Sass with Gulp and an intro to our component naming convention.

## Folders

Each folder contains an "index" file that's named after the folder. This file imports everything else in that folder. For example: `/vendor/` contains `_vendor.scss` and that file imports all its siblings.

When using `@import`, alphabetize the order of imports unless the cascade requires otherwise. In that case, leave a comment explaining the cascade goal.

### `/vendor/`

Most vendor libraries (Sass libs you get from another dev/source & don't change) will end up in `/node_modules/`, but if not, they'll go here.

### `/base/`

Base is a boilerplate category: variables, functions, mixins, etc. It doesn't contain blocks of styles, but helper code you'll use to write other styles. IOW, if you compiled the `/base/` dir alone, you should get an empty CSS file.

### `/elements/`

Elements contain styles that only apply to HTML tags, for the most part: typography, form elements, etc.

### `/components/`

Components are the smallest reusable patterns. They contain multiple elements, but not other components.

Whenever possible, scope component variations to selectors availabe on the component itself. For example, a "label + field component" _inside a modal_ might have different colors/borders from the default. Scope the variation to `.label-field.in-modal`, not `.modal .label-field`.

Components should usually have matching PHP. Small components might be generated by functions, included partials, or shortcodes. Sass partials should be named after the component's root class.

### `/modules/`

Modules can contain components and other modules. Modules styled in this folder are available to multiple pages, but not necessarily used on _every_ page.

Whenever possible, scope module variations to selectors availabe on the module itself. For example, a sidebar _on the home page_ might have different styles from the default. Scope the variation to `.sidebar.on-home-page`, not `.home-page .sidebar`.

Modules will have matching PHP files: included partials, or shortcodes. Sass & PHP file names should match the module's root class.

### `/global/`

Global contains the modules are part of the site global design and appear on every page.

Same rule about handling scoping as above: add a unique selector, not a parent scope.

### `/pages/`

Most of the code you would've been tempted to put into page-specific scopes on individual modules will already be handled through on-element variant selectors as described above. Occasionally you'll still find a page that has some unique styles that no other page should ever use. In that case, create a partial for that page here. The Sass partial should have the same file name as the WP template file that generates the markup. For example, any styles unique to `page-home.php` would be stored in `/pages/page-home.scss`.

This directory should be prone to frequent refactoring: as soon as any part of a "unique" page design is used on another template, refactor and move it to `/modules/`. Refactor your PHP too.