danielebarchiesi@0: /*******************************************************************************
danielebarchiesi@0:  * _components.scss
danielebarchiesi@0:  *
danielebarchiesi@0:  * Imports more partials that contain full components (modules in SMACSS), their
danielebarchiesi@0:  * sub-components and modifiers.
danielebarchiesi@0:  *
danielebarchiesi@0:  * Components are discrete parts of your page that should sit within the regions
danielebarchiesi@0:  * of your layouts. You should try to abstract your components as much as
danielebarchiesi@0:  * possible to promote reuse throughout the theme. Components should be flexible
danielebarchiesi@0:  * enough to respond to any width and should never rely on context
danielebarchiesi@0:  * (e.g. .sidebar-first .component) for styling. This allows modules to be
danielebarchiesi@0:  * placed throughout the theme with no risk of them breaking.
danielebarchiesi@0:  *
danielebarchiesi@0:  * If you find you need to change the look of a component depending on it's
danielebarchiesi@0:  * context you should avoid using context based classes at all costs. Instead it
danielebarchiesi@0:  * is better to add another "modifier" class to the component to alter the
danielebarchiesi@0:  * styling. Again, this promotes reuse.
danielebarchiesi@0:  *
danielebarchiesi@0:  * Sub-components are the individual parts that make up a component. As a
danielebarchiesi@0:  * general rule, adding a class to target a sub-component is a much better
danielebarchiesi@0:  * option than using descendant selectors or element selectors. In many cases
danielebarchiesi@0:  * sub-components can be made more reusable by making them components in their
danielebarchiesi@0:  * own right, so they can then be used within other components.
danielebarchiesi@0:  *
danielebarchiesi@0:  * Almost everything that doesn't belong in base should be made a component.
danielebarchiesi@0:  * Here's some common examples throughout Drupal:
danielebarchiesi@0:  *
danielebarchiesi@0:  * - Blocks
danielebarchiesi@0:  * - Content Types - For example, you may have a generic node component that
danielebarchiesi@0:  *      contains sub-components for the submitted by line and links. Specific
danielebarchiesi@0:  *      components can then be created for each content type to style the
danielebarchiesi@0:  *      specifics of each. Finally, by using entity view modes you can easily
danielebarchiesi@0:  *      apply modifications based on the .node-[view-mode] classes.
danielebarchiesi@0:  * - Forms - For instance the log in form.
danielebarchiesi@0:  * - Views - Each views output style could be made into a component, the content
danielebarchiesi@0:  *       of each row should be provided my a view mode styled by it's component
danielebarchiesi@0:  *       CSS. Exposed filter forms, views pagers and other views elements are
danielebarchiesi@0:  *       also good candidates for components.
danielebarchiesi@0:  ******************************************************************************/