Code Style Guide
If you would like to contribute to this website's code, please adhere to the following code style guidelines.
- Please try to keep lines at a maximum of 80 characters.
- Favor clarity over brevity in naming anything.
- Pages end with
- Partials and layouts end with
- Use well-formed markup; elements are nested properly and do not overlap.
- Write elements and attributes in lowercase.
- Quote all attributes.
- Self-close empty elements with a space before the trailing slash: (
This website uses Sass in the SCSS syntax. Make sure you’re using the classes that we have to offer before rewriting something, unless you can justify otherwise.
- Use the style Brad Frost writes about for clarity:
- Note that older classes do not use this style yet, but we will refactor over time.
- Use a
- Use the class prefixes Harry Roberts advocates, though we are using a much simpler set:
c-is for components. Example:
l-is for layouts. Example:
sl-l-grid. this double-dash syntax in a bit).
has-for states. Example:
- Use the BEM syntax.
- Block – the overall component object. Example:
- Element – any child of the block. Example:
- Modifier – any variation. This can be put on a block. Example:
sl-c-card--primary. It can also be put on an element Example:
- Keep classes as flat as possible, and avoid nesting too deep.
- Avoid using element selectors unless you’re using a wrapper utility to target everything inside (such as a class around a block of markdown or other longform text to style all its elements properly). This is specifically for when it doesn’t make sense to use classes. Be mindful when do this. We can give you feedback in a code review for instances like this.
- For naming of variables, mixins, placeholder selectors, or classes, use the general-to-specific approach. See this article for more details.
- Write comma-delimited selectors on separate lines.