April 2016 - MiniCamp Atlanta - SMACSS - Preparing Drupal 8 CSS Organization
smacssPREPARING DRUPAL 8 CSS ORGANIZATION.
SMACSS in Drupal 8 is not required or a standard.
However, it is a best-practice.
Implementing SMACSS in Drupal 8 is a work-in-progress.
A NOTE TO THE READER.
Follow along: https://www.drupal.org/node/1887922
A LITTLE ABOUT MYSELF.
Web Manager at the College of Engineering at
President of the Atlanta Drupal User’s Group.
Doctoral student at Georgia State University.
Learn more: http://www.webbeh.com
cssorganizationTHE NEVER-ENDING STRUGGLE FOR SANITY.
CONTROL-F ALL DAY.
CSS best-practices in Drupal 7 didn’t exist beyond basic
So, many of your theme frameworks have lots of different
confusing CSS organization.
Go back in time: https://www.drupal.org/node/302199
SMACSS (pronounced “smacks”) is more style guide than rigid framework.
There is no library within here for you to download or install. SMACSS is a
way to examine your design process and as a way to fit those rigid
frameworks into a flexible thought process. It is an attempt to document
a consistent approach to site development when using CSS.
SMACSS follows object-oriented programming (OO) in that its goals are to:
Increase the semantic value of a section of html and content
Decrease the expectation of a specific html structure
More generally, SMACSS’ focus is on locating and organizing patterns
throughout your CSS so that it is reusable and easier to segment and
SMACSS’ design is intended to be a starting point (not an end-all) to
building a style guide and CSS standard.
Organization is not rigidly defined.
A NOTE TO THE READER.
Base rules are applied directly to elements through element selectors,
descendent selectors, child selectors, pseudo-classes, however not specific
class or ID selectors.
(remember reset.css? this is where that goes)
Layout rules apply directly to the sizes and locations of your major
template components (header, footer, sidebar, main area).
Minor page components include navigation bars and widgets. They tend to
be inside layout components and even within other modules.
Modules should be designed so they can exist on their own, which gives
them greater flexibility in being combined and moved around to different
parts of the design without breaking the layout. With modules we do want
to avoid IDs and element selectors. More reuse means classes.
A state is something that augments and overrides all other styles.
States are generally applied to the same element as a layout rule or
applied to the same element as a base module class.
A theme defines colors and images that give your application or site its
look and feel.
Themes can affect any of the primary types. It could override base styles
like default link colors. It could change module elements such as chrome
colors and borders. It could affect layout with different arrangements. It
could also alter how states look.
module_name.module.css: This file should hold the minimal styles needed
to get the module's functionality working. (layout, component state styles).
module_name.theme.css: This file should hold extra styles to make the
module's functionality aesthetically pleasing. (theme styles).
module_name.admin.css: This file should hold the minimal styles needed
to get the module's admin screens working. (layout, component state
On admin screens, the module may choose to load the *.module.css in
addition to the *.admin.css file.
module_name.admin.theme.css: This file should hold extra styles to make
the module's admin screens aesthetically pleasing. (theme styles).
File structure for Drupal 8 theme CSS:
Note: Modules should never have any base styles.
Drupal core's modules do not have any base
styles. Instead Drupal core uses the Normalize.css
library augmented with a drupal.base.css library.
helpwithsmacss?CSS preprocessors to the rescue.
Sass (and contributed plugins) help to encourage
consistency through the usage of mixins,
variables, loops, and libraries.