|
// ---------------------------------------------------------------------------- |
|
// 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) |
|
// - $column : [location | first, last <explicit>] [<width> | <columns-span> of <column-count> | <fraction>] [push <count> | pull <count>]; |
|
// : first - Remove 'outside before' gutters |
|
// : last - Remove 'outside after' gutters (and reverse?) |
|
// : 3rd - Explicit location |
|
// : 2 - Columns in context (root) |
|
// : 3 of 6 - Columns in context (explicit) |
|
// : 2/6 - Fraction |
|
// : push 3 - Push |
|
// : pull 3 - Pull |
|
// - $modifiers : [reverse] [in <context>] [gutter | <width>] [margin | <margin>]; |
|
// : reverse - Float the other direction |
|
// : in 960px - Modify column context |
|
// : in 75% - Modify column context |
|
// : gutter 2% - Modify gutter |
|
// : margin 10px - margins |
|
// : margin 6px 10px - irregular margins |
|
|
|
// Example: 4 of 10 Columns, pushed 3 |
|
.item { |
|
@include grid-span(4 of 12 push 3); |
|
} |
|
|
|
// Example: Same as above using a fraction |
|
.item { |
|
@include grid-span(4/12 push 3); |
|
} |
|
|
|
// Example: Write a column of an arbitrary width. |
|
.item { |
|
@include grid-span(30%); |
|
} |
|
|
|
// Example: second 3 of non-uniform Columns pushed 1, new gutter .2 |
|
.item { |
|
@include grid-span(2nd 3 of (2 1 5 1 3 3) push 1, gutter .2); |
|
} |
|
|
|
// Example: second 3 of non-uniform Columns pushed 1, new gutter 16px |
|
.item { |
|
@include grid-span(2nd 3 of (100px 60px auto 60px 140px 140px) push 1, in 960px gutter 16px); |
|
} |
|
|
|
// Example: Same as above, assuming global grid is OK. |
|
.item { |
|
@include grid-span(2nd 3 push 1); |
|
} |
|
|
|
// Example: span 5 columns assuming global grid, floats, and uniform columns |
|
.item { |
|
@include grid-span(5); |
|
} |
Let me weigh in on some of this:
Isolation vs Float
I really dislike the idea of automatically assuming isolation/float based on how syntax. Output style needs to be explicit because there are significant and potentially unexpected issues with using one over the other, so what output style that gets used needs to be a user choice not a system assumption. Both Float and Isolation work perfectly well for uniform/symmetric and non-uniform/asymmetric grids, and by explicitly requiring users to define their output style it opens us up to other output styles and a plugin output architecture. It also keeps up future friendly.
Where Are You
I'm a big fan of the natural language stuff we've got going on here, but let's take a step down and think about the code. As we all know, Sass's built in functions for string parsing aren't so great, so we're going to need to set our syntax to something that's easily parseable with this in mind. As such, I'm in favor of the
at/to
syntax as opposed to an ordinal number system. It's going to make it much easier come code time for us to parse. It's also easier to grok if you're not a native English speaker as ordinals are fracking strange.At/Push/Pull
Here's where stuff, in my mind, starts to get tricky. At can, as a concept, take on entirely different meanings depending on whether your output is symmetric, asymmetric, float, or isolation. Let's break it down:
at
very easily can mean push/pull (althoughspan(3 at -1)
seems a bit odd to me).span(3 at 2)
sounds like it could be a push.at
more easily portrays column on grid andpush/pull
more easily portrays positioning.Hopefully that's clear and shows a clear need for both
at
andpush/pull
in the system, Because we have a strong need for both, we could either say that symmetric grids have one syntax and asymmetric grids have another, or I believe that for symmetric grids, whileat
can work,push/pull
can work equally well and we can have a unified syntax across both types of grids, making the DX better in the end and making switching between output methods nice and easy.With all of this being said, I think that while we can have
push/pull
functionality built in to+span()
, we need to also have+push()
and+pull()
. Something I frequently do is lay out a base grid for major page components using one grid and have items inside that grid laid out on another. True compound gridding. In this case, I have the need to push/pull not only along the grid I'm currently on, but along a different grid altogether. As such, we need a distinct way to enable this, and I think trying to cram it all into a single line is a bit much. Separate mixins are required.Global Variables
While I agree and fully support the need to be able build an entire grid from
+span()
, I do still believe that we need some global variables. Specifically, the following (with inline overrides as needed):$grids
: A way for users to define major grid changes at given breakpoints.$output
: The default output method. Could be overridden withusing float
.$border-box
: Boolean. Includebox-sizing: border-box
on all grid items or not. Could be overridden withwith border-box
orwithout border-box
.$clearfix
: Boolean. Include a clearfix on all grid items or not. Could be overridden withwith clearfix
orwithout clearfix
.Defining The Grid, Breakpoints, and Containers
Back to the string parsing issue I brought up in float/isolation, IMO we're going to need a slightly more verbose syntax for defining an individual grid than currently proposed simply due to parsing issues and uneven numbers of variables (unless one of us is a natural language parsing savant that I'm not aware of). I'm not sure what that's going to need to be ATM, but I think it's going to be needed.
As for defining breakpoints and containers, I actually really hate column based breakpoints. I understand people use them, but they are always desktop-first approaches and rarely if ever actually line up with what your content needs. While having it as an option for those who want it, it needs to be much more explicit in what it's looking for including a min or max column width. This is especially true when talking the compound math that we're using in Singularity and what we should be using in Susy Next (screw 2.0, Susy Next!) as everything boils down to, and can be explicitly set as, unitless numbers. We also need to take into consideration, especially if we're writing container widths in
ems
, changing base font sizes (aka font scaling) at different breakpoints and taking that math into account. We also need to be able to explicitly provide a progressive enhancement fallback. I also think it should be called+container()
not+grid()
as we're not adding a grid, but rather adding a container.Overall Thoughts
Generally speaking, I think we must follow the below principles when architecting Susy Next in order to accomplish not only what we individually want, but for our users and for future friendliness:
border-box
orclearfix
should be up to the user to decide. We should not, for instance, assume that the type of grid they want to use should dictate the output. Any of these assumptions will make it harder for us to keep future friendly and generally be flexible.300px 600px 250px 300px
into a3 6 2.5 3
grid, but users should never be under the assumption that their bad habits are going to be rewarded. An instance of this (please do not take offense Eric) is assuming a grid of12 4em 1em
will create a 60em container. This is a bad habit because this is a desktop first approach to building a grid; the way we break people of this bad habit is by requiring containers to be set explicitly, separating the relational grid math from the design container code.I think that's enough for this morning. For everyone who celebrated, hope everyone had a great Christmas!