You are free to contribute to Chopstick via GitHub Pull Requests (more on that later). Be like a good scout: if you find something you can improve, however small, fix it and send us a pull request. Many small improvements over time attribute to something greater!
We have a couple of simple guidelines we try to follow, of which most are taken from the CSS Tricks Sass Style Guide
- We close issues after 14 days of inactivity
- You can comment on pull requests during 7 days
A successful git branching model
- Fork this repo.
- Create a branch
git checkout -b feature--name - Commit your changes
git commit -am "New feature" - Push to the branch
git push origin feature--name - Open a Pull Request
We use Editorconfig to maintain a consistent coding style. Please take care of proper spacing and indenting.
We use the BEM naming methodology:
.blockfor sole root of the component (eg: .c-widget).block__elementfor a component part of the block (eg: .c-widget__title).block--modifierfor a variant or extension of the block (eg: .c-widget--full)
Follow these rules for namespacing:
.o-for object classes (eg: .o-media).c-for component classes (eg: .c-widget).t-for theming classes (eg: .t-header).u-for utility classes (eg: .u-1-of-2).is-/.has-for stateful classes (eg: .is-active)- .js for javascript hooks
._for temporary hacks/fixes
- Regular styles
- @includes
Example:
.c-component {
background: #fff;
@include transition(all 0.3s ease);
}
Don't use @extends as they have a tendency to cause css bloat and long selectors.
Try to avoid nesting. We follow a single-depth-class-based architecture.
Only @include in the global screen.scss file. Never write SCSS directly in screen.scss. Order of importing is always as described in screen.scss.
Comments get filtered out when compiling. If you do anything that can not be immediately understood: comment it.