layout.scss

// ----------------------------------------------
// I want to define the important layout settings

// $columns: <integer> | <list>;
$columns: 12;

// $gutters: <ratio>;
$gutters: .25;

// $column-width: auto | <length>;
$column-width: auto;

// $container: auto | <length>;
$container: auto;

// -----------------------------------------------------
// I want to store an entire layout in a single variable
//
// - [container], columns, spacing
// - container is an (optional) length
// - columns can be an integer or list
// - spacing defines column-to-gutter size as two lengths, or single float ratio
//   (these can be used to set $column-width and $gutters)

$symmetrical: 4 .25;
$symmetrical-specific: 960px 12 (60px 20px);
$symmetrical-extended: (1 1 1 1) .25;

$asymmetrical: (1 3 5 2 1) .25;
$asymmetrical-specific: 80% (1 3 5 2 1) (3em 1em);

// --------------------------------------------------
// I want to override all the global settings at once

$any-layout: 660px 12 (60px 20px);

@include set-layout($any-layout);

// ------------------------------------------
// I want to use explicit breakpoint handling
//
// - set a breakpoint (using breakpoint plugin)
// - set a layout

$breakpoint: 50em;
$large: 12 .25;

@include breakpoint($break) {
  @include layout($large) {
    /* do what I want */
  }
}

// ---------------------------------------
// I to return the width of a column-group
//
// - columns
// - [optional] context
// - [optional] location

$width: span(3);
$nested: span(3 of 6);
$asymmetric: span(3 at 3 of (1 3 5 4 2));
$shortcut: span(last 3 of (1 3 5 4 2));

// ---------------------------------------------
// I want to return the width of a single gutter
//
// - [optional] context

$gutter: gutter();
$gutter: gutter(6);
$gutter: gutter(1 3 5 6 4 2);

I'm concerned about this syntax for a few reasons:

1. The break syntax and establish-breakpoints set up a bad mental model for users. Unlike traditional grids where a physical grid gets built, these are ethereal grids; we are not breaking at those points we are changing the major context at those points. No breakpoints should get written, and the grid the user has set up doesn't break there. The word break is also ambiguous; does my grid start or stop there? If it's start there, can I specify a "first grid" with no media query attached to it to cover everything before that point? If it's stop there, can I specify a "last grid" with no media query attached to it to cover everything after that point? Additionally, being able to mix min-width and max-width can lead to, and in your example does lead to, ambiguity in the context to be used. Line 18 translates to min-width: 640px, 19 to max-width: 800px and 20 to 'min-width: 500px, max-width: 800px`. If I have a MQ at 700px, which context am I in?

2. What is purpose of $default-layout? Is it to provide a layout outside of the ones defined in your initial setup? If so, I'm not sure $default-layout is the proper syntax. If it's to provide layout options for those outside of the context defined in 1), do you think it'd be better to provide that as part of that definition to keep those definitions together? If it's to provide a context override, I think it should be named something different, however, in that case, what's the difference between that and the layout mixin?

3. How can users choose which output style to use? Can they choose their output style on the fly, mixing float, isolation, flexbox, or anything else that comes out in the future? Can they choose their output style at all? Is this syntax flexible enough to accommodate the different mental models required for each output style (float: walking across a row, isolation: isolated placement on a grid, flexbox: orientation and directional based)?

1a) I'm not sure I understand the first part of this concern. What do you mean about the mental model?

1b) I see how min+max is a problem for something like your automated context-finding magic, but I find it very useful otherwise. My proposal is to drop any tight media-query integration for now. Using breakpoint() along with layout() is both flexible and completely de-coupled. Adding in at-breakpoint() functionality later is simply a matter of sugar, and I think magical-context-finding should be as well. Let's drop it all for now, and re-visit at the sugar phase?

2. Yeah, $default-layout was dumb. I've split out the different parts of a layout into initial default variables, and added a mixin for setting them all at once using the shorthand syntax. Now layout() { ... } establishes settings within its @content while set-layout() simply overrides the variables globally.

3. Good question, I haven't addressed it yet, but I don't think we have anything that will conflict (I haven't thought carefully about flexbox though). I've also expanded the setting options so that static would be a possible output (we have to know actual widths for that one, not just relative ratios). I don't consider this document complete - I'm still trying to think through all the implications.

static wouldn't be on the same level as float/isolate/flexbox of course - that would be a different thing, but still an output-related setting.

Now that I think about it, I wonder what flexbox grids actually would look like. I don't really know. Has anyone done a lot of work on that?