Truss is a Parent theme with the goal of making it fast to build responsive WordPress child themes, with semantic HTML.

It makes this process fast by:

• Organizing CSS into Sass partials segregated by purpose, to ease re-skinning.
• Relying on WordPress hooks to load template partials, to ease supplementing, replacing, re-ordering, and removing template elements.
• Providing great documentation for child theme developers to come up to speed as quickly as possible.

At a glance, Truss uses:

• A modified version of _s (Underscores) for markup.
• An opinionated method of organizing and writing CSS

• A modified version of _s (Underscores) for markup.

• An opinionated method of organizing and writing CSS, including:

  • The Object-oriented CSS philosophy
  • The Scalable and Modular Architecture for CSS (SMACCS) philosophy.
  • Digesting vendor stylesheets (such as resets) and stitching them intentionally into our partials to boost performance by minimizing rules overwriting rules.
  • Sass, Bourbon, and Neat for Responsive grids.
  • Sass-globbing to include Sass partials in bulk
  • Normalize to reset CSS.

• Theme Hook Alliance hooks to ease extension by plugins.

• Genericons and Dashicons icon fonts

• Flexnav responsive navigation menu system

• TGM Plugin Activation to recommend and require plugins

Truss takes a progressive enhancement approach, meaning that baseline support is guaranteed for an arbitrary list of older browsers, and enhanced CSS is served to newer browsers based on capatilbitiy detection.

Truss authors have verified Truss styles behave as expected in these browsers:

(@todo replace "latest version" with specifics, as of release-time.)

• The latest version of these browsers for Mac OS X 10.10 and above:
  • Chrome
  • Firefox
  • Safari
• The latest version of these browsers for Windows 8 and above:
  • Internet Explorer (IE 8 and later) (@todo verify)
  • Firefox
  • Chrome
• iPhones: (@todo)
  • 4s (Mobile Safari X.X)
  • 5 (Mobile Safari X.X)
  • 5s (Mobile Safari X.X)
  • 5c (Mobile Safari X.X)
  • 6 (Mobile Safari X.X)
  • 6 plus (Mobile Safari X.X)
• iPads: (@todo)
  • 2 (Mobile Safari X.X)
  • 3 (Mobile Safari X.X)
  • Air (Mobile Safari X.X)
  • Air 2 (Mobile Safari X.X)
  • Mini (Mobile Safari X.X)
  • Mini 2 (Mobile Safari X.X)

Follow the SMACSS.com book's recommendations for writing and organizing CSS selectors and rules. These recommendations result in CSS that is scalable and easier to maintain, by making as few assumptions about HTML structure as possible (if they need to change in the future, we aren't handcuffed), and by limiting the potential for changes and additions to have unintended consequences.

We follow the books's philosophy, but not all of its specific recommendations. Using Sass allows us to organize things contextually, and gives us new flexibility for documenting CSS, which frees us from some non-semantic recommendations of the SMACSS book. For example, we don't use l- to prefix layout class names. That approach is arguably non-semantic, and is no longer necessary when we can provide documentation of every CSS rule in a Sass partial.

Build visual/UI elements as standalone, reusable "objects", or pieces — modules, essentially — that have no knowledge of their parent container.

Objects may be responsible for layout, or a visual component, but generally not both. Contextual page layout is always treated separately from visual components.

Do not: Re-use existing HTML classes for new CSS purposes.

Do: Create a new HTML class / CSS selector pairing when you need to define new objects.

Do not: Supplement or modify existing style rules without considering whether your changes should apply to all instances of that class in HTML — current or future, known or unknown.

Do: Supplement or modify existing style rules for a given class when you intend to change any instance of the module site-wide.

Do: Keep all code to do with a single class in as few places as possible: Ideally one CSS selector per class.

• Tutsplus Tutorial on OOCSS

The Single Responsibility Principle: every class should have a single responsibility, and that responsibility should be entirely encapsulated by the class.

Do not: write CSS selectors targeting existing classes in HTML that may be used for other purposes.

Do: Create a new, reusable, semantic classes to target against, to avoid collisions with current or future style rules leading to !important hell when yours are applied too broadly and overwrite the cascade in unforseeable ways.

Sass partials are organized into the following folders, sorted in import-order, which is based on dependency ordering:

• sass/globals/ - everything that does not print out to CSS.
  • sass/globals/frameworks/-
  • sass/globals/variables/ -
  • sass/globals/functions/-
  • sass/globals/mixins/ -
  • sass/globals/extends/ -
  • Note: You should be able to re-skin the entire theme by modifying only the contents of the variables/ and extends/ directories.
• sass/base/ - Everything that is not for layout and is not specific to a module. Primarily HTML tag-specific rules.

…

For more, see the SMACSS chapter on base styles.

…

…

For more, see the SMACSS chapter on layout styles.

…

Modules are minor groups of content, subordinate to layout, with a distinct and discrete visual design that makes them appear as a whole.

Modules are completely ignorant of their containing elements. If you move them from inside of one layout container to another, its appearance and behavior should not change.

From an object-oriented perspective, they are objects of a given class, and so their markup should identify the class and their CSS should implement a self-contained and self-determining encapsulation. (The same can be said of their JavaScript.)

For more, see the SMACSS chapter on module styles.

…

Avoid conditional styling based on location. If you are changing the look of a module for usage elsewhere on the page or site, sub-class the module, instead.

To subclass a module, add a class to it, prefixed with the module name. For example:

<!-- "Product" is the base class -->
<div class='product'>
	<span class='prod-name'>…</span>
	<span class='prod-vendor'>…</span>
</div>

<!-- "Product On Sale" is the sub class -->
<div class='product product-onsale'>
	<span class='prod-name'>…</span>
	<span class='prod-vendor'>…</span>
</div>

The SMACSS Book explains that what distinguishes state from sub-modules are two things. We add a third distinction, to further clarify:

1. State may be applied to both layout and module objects.
2. State is changeable during the lifetime of the application, dependent on JS (whereas modules are set and do not change).
3. State is supplemental to modules, in that they are often (perhaps most of the time) module-dependent. In otherwords, state is not entirely meaningful without a module (or layout) context.

For more, see the SMACSS chapter on state styles.

Truss' Sass partial organization splits the location of state styles into two different areas:

• Generic state classes are located in sass/state/.
• Module-dependent state classes are located in sass/modules/, in their module contexts as nested Sass selectors.

Generic state classes can be thought of as ignorant of their module contexts, in a similar way as modules are ignorant of their location contexts.

An example: sass/state/_truss_is-hidden.scss:

.is-hidden {
	display: none;
}

Grouping generic states allows defining them once, allowing modules to share them without having to re-define them, which reduces redundancy.

Module-specific state classes are unique to a module, or behave uniquely in a module. They should be grouped with their module's definition, as a nested Sass selector.

A hypothetical example:

@todo

In the unusual event that a module needs to override a generic state class, that is easily done by the same mechanism.

Truss packages TGM Plugin Activation, a PHP library that allows you to easily require or recommend plugins. It allows your users to install and even automatically activate plugins. You can reference pre-packaged plugins, plugins from the WordPress Plugin Repository or even plugins hosted elsewhere on the internet.

To use TGM Plugin Activation in your child theme:

1. Copy truss/library/child-themes/child-theme.php into the root of your child theme
2. Follow instructions in this file.

For more information, refer to truss/library/vendors/tgm-plugin-activation/README.md.

• Theme Root
  • library
    • assets ( js, css, sass )
      • css
      • font
      • js
      • sass ( Where all scss files are stored )
    • languages
    • vendors ( 3rd party utilities like Theme Hook Alliance, TGM Plugin Activation etc... )
  • page-templates ( Standard Page Templates for Pages )
    • partials ( Template Parts via get_template_parts() )

Truss is a project of Rocket Lift, whose technical team includes:

• QA engineer Catherine Bridge
• Support tech Douglas Detrick
• Lead developer Matthew Eppelsheimer
• Sysadmin and QA engineer Matt Pearson

If you are Truss, and/or you'd like to collaborate on its development, please let us know!

This theme began as a fork of Alex Vasquez's Some Like It Neat.

This theme is based on Underscores, (C) 2012-2013 Automattic, Inc.

• Source: http://underscores.me/
• License: GNU GPL, Version 2 (or later)
• License URI: license.txt

Flexnav, Copyright 2014 Jason Weaver.

• Source: http://jasonweaver.name/lab/flexiblenavigation/
• License: GNU GPL, Version 2 (or later)
• License URI: https://github.com/indyplanets/flexnav/blob/master/LICENSE

Genericons, Copyright 2013 Automattic, Inc.

• Source: http://www.genericons.com
• License: GNU GPL, Version 2 (or later)
• License URI: /font/license.txt

Theme Hook Alliance

• Source: https://github.com/zamoose/themehookalliance/blob/master/tha-theme-hooks.php
• License: GNU GPL, Version 2 (or later)
• License URI:

Bourbon

• Source: http://bourbon.io, © 2013 thoughtbot
• License: The MIT License
• License URI: https://github.com/thoughtbot/bourbon/blob/master/LICENSE

Neat

• Source: http://neat.bourbon.io, © 2013 thoughtbot
• License: The MIT License
• License URI: https://github.com/thoughtbot/neat/blob/master/LICENSE

Hover Intent

• Source: https://github.com/tristen/hoverintent
• License: the MIT
• License URI: license.txt