Code organisation

Each component resides in its own folder. The folder contains the following files:

• _component-mixins.scss Contains all the style rules for the component and its variants. All styles should be placed in mixins, and explicitly declaring sectors should be avoided (except pseudo selectors as needed).

• _component-variant-a.scss, _component-variant-b.scss, etc Each variant of the component (such as primary and secondary, etc) is declared in a separate scss file. This file contains the css-selector declarations for the variant, and will produce css output when imported.

• _component.scss Collection import of the component. This file should be named the same as the component, and import all of the variants. This is the file that the user imports when the need all variants of the component.

Mixin names should follow the BEM naming convention, and be prefixed with ´vanilla-´ For example, @mixin vanilla-tabs__tab--active() { ... } would contain css rules for the active state of the tab element of the tabs component.

Each component should have one mixin named vanilla-component-name() that includes all the styles for that component. This mixin should only contain selector declarations and calls to other mixins.

Example: https://github.com/sebgroup/vanilla-pattern-library/blob/dev/src/components/tabs/_tab-mixins.scss

Component variants Variants should be named vanilla-component-name-variant-name and should add to or modify the base variant of the component. They should be designed to generate an additional class that can be used together with the base variant class. Example: Base variant: vanilla-button, produces the class .sdv-button Secondary variant: vanilla-button-secondary, produces the class .sdv-button-secondary Designed to be used like this: <button class="sdv-button sdv-button-secondary">

The goal for Vanilla components is

1. High granularity.
2. Minimize risk of conflicts with other frameworks
3. Low css output size.