The Rules

• We use classes; ID's are the devil
• Components (The C in CEM) are a chunk of markup that works together;
  e.g. a menu, a teaser, a who's online widget, a social share widget, an article.
• An element (the E in CEM) is a piece of the whole.
  e.g. a title, some text, an image, call to action link.
• A modifier is a suffix that can denote a slightly different version of a Component or Element

• Names are '-' delimited (this goes for a C, E or M)

  .component-name {}

• Element classes have the component's name, then their name with a double underscore separator

  .component-name__element-name {}

• Modifiers are added to the end of a component or an element and are separated by a dash.

  
  .component-name--modifier-name {}
  .component-name__element-name--modifier-name {}

Core's Base Themes

Both have well organized files, and all of the templates from core.

Ride the roller coaster!

In your *.info.yml add:

base theme: false

Core markup and classes could change and could effect your site.

Simple, Static Data

Drupal 7

$title
$content['field_body']
$myvar['has']->alot['of']['nesting']['und'][0]->safe_value

Drupal 8

Dot notation

{{ title }}
{{ content.field_body }}
{{ myvar.has.alot.of.nesting.safe_value }}

Tricksy Datas

Drupal 7

$my_array[$index]
$element['#id']

Drupal 8

{# Since I want to use a variable called index #}
{{ my_array[index] }}

{# Since this index starts with a hash #}
{{ element['#id'] }}

Behind the scenes:

/**
 * If you have {{ sandwich.cheese }} in your twig, it checks:
 */
// Array key.
$sandwich['cheese'];
// Object property.
$sandwich->cheese;
// Also works for magic get (provided you implement magic isset).
$sandwich->__isset('cheese'); && $sandwich->__get('cheese');
// Object method.
$sandwich->cheese();
// Object get method convention.
$sandwich->getCheese();
// Object is method convention.
$sandwich->isCheese();
// Method doesn't exist/dynamic method.
$sandwich->__call('cheese');

twig.sensiolabs.org/doc/templates.html#variables

In other words...

{{ what.does.this.do }}

Filter strings!

{# Send translatable string through t function #}
{{ 'Translatable String'|t }}

{# Make a string fit to be a HTML Class #}
{{ node.bundle|clean_class }}

{# Get the string length #}
{% set title_length = title|length %}

There are plenty more:
twig.sensiolabs.org/doc/filters/index.html
drupal.org/node/2357633

Apply a string filter to a block of text

  {% filter trim %}
    Trim will eliminate this     weird    white   space
  {% endfilter %}

Info.yml

# fluffiness.info.yml
name: Fluffiness
type: theme
description: A cuddly theme.
package: Custom
core: 8.x
libraries:
  - fluffiness/global-styling
regions:
  header: Header
  content: Content
  sidebar_first: Sidebar first
  footer: Footer

drupal.org/node/2349827

Creating a sub theme

# fluffiness.info.yml
name: Fluffiness
type: theme
description: A cuddly theme.
package: Custom
core: 8.x
base theme: classy

drupal.org/node/2165673

Libraries.yml

# fluffiness.libraries.yml
global:
  version: 1.x
  css:
    theme:
      css/layout.css: {}
      css/style.css: {}
      css/colors.css: {}
      css/print.css: { media: print }

drupal.org/theme-guide/8/assets

Define Libraries that can consist of JS and CSS

# Further down in fluffiness.libraries.yml
cuddly-slider:
  version: 1.x
  css:
    theme:
      css/cuddly-slider.css: {}
  js:
    js/cuddly-slider.js: {}

drupal.org/theme-guide/8/assets

Declare dependencies on other libraries

# We forgot our jquery dependency!
cuddly-slider:
  version: 1.x
  css:
    theme:
      css/cuddly-slider.css: {}
  js:
    js/cuddly-slider.js: {}
  dependencies:
    - core/jquery

drupal.org/theme-guide/8/assets

Using Twig

For most use cases, you can tie a library to markup using attach_library()

{{ attach_library('fluffiness/cuddly-slider') }}
<div>Some fluffy markup {{ message }}</div>

drupal.org/node/2216195

Using PHP

In your .theme file you can use PHP to add the library using whatever logic you'd like.

<?php
function fluffiness_preprocess_maintenance_page(&$variables) {
  $variables['#attached']['library'][] = 'fluffiness/cuddly-slider';
}

function fluffiness_preprocess_page(&$variables) {
  if ($variables['fluffiness'] >= 5000) {
    $variables['#attached']['library'][] = 'fluffiness/cuddly-slider';
  }
}

drupal.org/node/2216195

Setup Twig Developer Settings

1. Find twig.config and change these values (should be in development.services.yml)

   # Will be buried in the file, search for 'twig.config'
     twig.config:
       debug: true

2. Add a settings.local.php file with:

   <?php
     $settings['cache']['bins']['render'] = 'cache.backend.null';
     $settings['cache']['bins']['dynamic_page_cache'] = 'cache.backend.null';

drupal.org/node/1903374

Replace a library or asset

# fluffiness.info.yml cont'd
libraries-override:
  # Replace an entire library.
  core/drupal.collapse: mytheme/collapse

  # Replace an asset with another.
  subtheme/library:
    css:
      theme:
        css/layout.css: css/my-layout.css

drupal.org/node/2497313

Removing an asset or entire library

# OR in fluffiness.info.yml
libraries-override:
  # Remove an asset.
  drupal/dialog:
    css:
      theme:
        dialog.theme.css: false

  # Remove an entire library.
  core/modernizr: false

drupal.org/node/2497313

Extend a library

# fluffiness.info.yml cont'd
# Extend drupal.user: add assets from classy's user libraries.
libraries-extend:
  core/drupal.user:
    - classy/user1
    - classy/user2

drupal.org/node/2497313

Render Types

<?php
$variables['link'] = array(
  '#type' => 'link',
  '#title' => 'Visit Lullabot',
  '#url' => 'https://lullabot.com',
  '#options' => array(
    'class' => array(
      'some-class',
    ),
  ),
);

Modifying Render Elements

Unfortunately, the easiest way I've found is to modify it in the preprocessor.

<?php
/**
 * Implements template_preprocess_menu_local_task().
 */
function frontendrapport_preprocess_menu_local_task(&$variables) {
  $variables['link']['#options']['attributes']['class'][] = 'admin-tabs__link';
}

ALL the theme_suggestions

hook_theme_suggestions_alter(array &$suggestions, array $variables, $hook)

I see less hook_form_alter() in your future...

Instead of using hook_form_alter() to add a bit of presentation to a form you can suggest a specific template for the form or any of it's fields!

Twig Extends

{# cool.html.twig #}
{% block foo %}
  Default content
{% endblock %}

Meanwhile...

{# cool-er.html.twig #}
{% extends "cool.html.twig" %}
{% block foo %}
  Alternate Content
{% endblock %}

twig.sensiolabs.org/doc/tags/extends.html

And you can even...

{# cool-er.html.twig #}
{% extends "cool.html.twig" %}

{% block foo %}
  {{ parent() }}
  Alternate Content
{% endblock %}

Editorial time...

Extends make a tonne of sense for custom Symfony applications...

But in Drupal land they might make code DRYer at the expense of being intuitive.