Susy 2.0 Proposal

about.md

About This Proposal

This is a very rough proposal for a radical Susy 2.0 API overhaul.

The basic goals are:

1. Flexible: Allow all the main layout approaches.

• float / isolation
• columns (symmetrical & asymmetrical) / fractions / explicit widths
• gutters inside or outside - before, after, or split

2. Simple: Less API is better.

• Less universal settings, everything can be controlled on-the-fly when possible
• Less mixins, with more power and flexibility

3. Moving Forward: Backwards functionality should be maintained.

• Anything you created in Susy 1.0 can be recreated in 2.0
• Layouts created in 1.0 do not need to work in 2.0 automatically

4. Light Touch: Always do the minimum possible to achieve a layout.

• If there's a question, less output is the answer.

5. Prepared: Plan ahead for flexbox & grid modules. (not considered yet in this proposal)

(Changes inspired largely by Singularity and Salsa, with elements from Zen as well.)

api.scss

// ----------------------------------------------------------------------------
// Settings

// $grid      : [<number> <settings> | <width> <complex-layout>] [inside | outside] [before | after | split];
// $direction : [left to right | right to left];

// Example: The current Susy default.
$grid         : 12 4em 1em 1em outside after;

// Example: The current Singularity demo.
$grid         : (1 2 3 5 2 3) .25;

// Example: The current Salsa default.
$grid         : 16 auto 20px inside split;

// ----------------------------------------------------------------------------
// Grid Container
//
// @include grid($width...)
// - $width   : <breakpoint> [static] <arbitrary with | column math>;
//            : 12 4em 1.5em               - Column math (explicit)
//            : 12 4em 1.5                 - Identical to above...
//            : break(25em) 8              - Breakpoint + column math (default)
//            : 60em                       - Arbitrary width
//            : static 60em                - Use 'width' instead of max-width

// Example: 4 column default width, breaks at 8 columns
.container { 
  @include grid(4, break(8)); 
}

// ----------------------------------------------------------------------------
// Grid-Spanning Element
//
// @include grid-span($width, $position)
// - $width     : [<width> | <columns> of <context> | <fraction>];
//              : 75%                      - Arbitrary width
//              : 2                        - Columns in context (root)
//              : 3 of 6                   - Columns in context (explicit)
//              : 2/6                      - Fraction
// - $position  : [at <location> | push <count> | pull <count>] [first | last] [reverse];
//              : push 3                   - Push
//              : pull 3                   - Pull
//              : at 3                     - Isolated location
//              : first                    - Remove 'outside before' gutters
//              : last                     - Remove 'outside after' gutters (and reverse?)
//              : reverse                  - Float the other direction

// Example: 4 of 10 Columns, pushed 3
.item {
  @include grid-span(4 of 10, push 3);
}

I went with grid-span here because column-span feels wrong when it is possible to do arbitrary widths. From there, it seemed reasonable that grid would be used to establish the element we are spanning. This is, of course, all up for debate.

Honestly, I think grid-span is even worse when using arbitrary widths and not the grid system.

regarding $width - I can see how 3 of 6 can be different then 3/6 as in non-uniform grids, but it still seems a bit confusing, maybe they can be united somehow.

on the $position side, it should be possible to not only do at 3 for container-relative floats but also at 30%.