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