SU-SWS/stanford_profile_helper

View on GitHub
modules/stanford_person/stanford_person.libraries.yml

Summary

Maintainability
Test Coverage
# Drupal 8 uses the SMACSS system to conceptually categorize CSS rules. Note
# that some SMACSS nomenclature has been changed to avoid confusion with
# existing Drupal terminology.
#
# Base
# Base rules consist of styling for HTML elements only, such as used in a CSS
# reset or Normalize.css. Base rules should never include class selectors.
#
# To avoid ‘undoing’ styles in components, base styles should reflect the
# simplest possible appearance of each element. For example, the simplest usage
# of the ul element may be completely unstyled, removing list markers and
# indents and relying on a component class for other applications.
#
# Layout
# Arrangement of elements on the page, including grid systems.
#
# " Grid systems should be thought of as shelves. They contain content but are
# not content in themselves. You put up your shelves then fill them with your
# stuff [i.e. components]. – Harry Roberts, CSS Guidelines "
#
# Component (SMACSS “module”)
# Reusable, discrete UI elements; components should form the bulk of
# Drupal’s CSS.
#
# State
# Styles that deal with transient changes to a component’s appearance. Often,
# these are client-side changes that occur as the user interacts with the page,
# such as hovering links or opening a modal dialog. In some cases, states are
# static for the life of the page and are set from the server, such as the
# active element in main navigation. The main ways to style state are:
#  * Custom classes, often but not always applied via JavaScript. These should be
#    prefixed with .is-, e.g. .is-transitioning, .is-open;
#  * pseudo-classes, such as :hover and :checked;
#  * HTML attributes with state semantics, such as details[open];
#  * media queries: styles that alter appearance based on the immediate browser
#    environment.
#
# Theme
# Purely visual styling, such as border, box-shadow, colors and backgrounds,
# font properties, etc. Ideally, these should be separated enough from a
# component’s structure to be “swappable”, and omitting these entirely should
# not break the component’s functionality or basic usability.
#
# EXAMPLE:
#
node:
  css:
    component:
      dist/css/stanford_person.node.css: {}
  js:
    lib/js/stanford_person.js: {}

views:
  css:
    component:
      dist/css/stanford_person.views.css: {}
  js:
    lib/js/stanford_person.js: {}
  dependencies:
    - core/jquery
    - core/drupal