Skip to content

Instantly share code, notes, and snippets.

@scottkellum

scottkellum/about.md

Forked from mirisuzanne/about.md
Last active December 10, 2015 00:38
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save scottkellum/4352403 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save scottkellum/4352403 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
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
  1. Simple: Less API is better.
  • Less universal settings, everything can be controlled on-the-fly when possible
  • Less mixins, with more power and flexibility
  1. 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
  1. Light Touch: Always do the minimum possible to achieve a layout.
  • If there's a question, less output is the answer.
  1. 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.)

Raw
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)
// - $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);
}
@scottkellum
Copy link
Author

scottkellum commented Dec 25, 2012

span(2 at 3) Can this trigger isolation only if it is used with a uniform grid? There might be instances where float method is preferred and the at 3 is still necessary to find width?

IDK, maybe I am over complicating things. Just seems like there might be use cases were this automatic behavior might not be wanted?

Maybe isolate at 3 or float at 3. We can have this magic but override it in explicit instances. IMO at should not be limited to an output mode, while it can trigger an output mode it worries me a little strictly tying it to an output mode. Just trying to think of a good way to float asymmetric columns instead of isolating them.

@mirisuzanne
Copy link

mirisuzanne commented Dec 25, 2012

One of us is misunderstanding, because I don't think there is any automatic or magic in my proposal. I'm not suggesting that at would automatically isolate asymmetric grids. I'm suggesting that at would have nothing at all to do with asymmetric grids. I'm suggesting that it would do isolation instead of, not in addition too asymmetric grids. So at would only do one thing, and it would do that one thing explicitly, without any magic.

And then, since we need a way to do asymmetric grids as well, I'm suggesting entirely separate solutions for that. My favorite approach for that is to declare a range of columns (e.g. 2 to 4 of (2 4 6 8 6 2) would span the 4 6 8 columns) rather than a column count and a starting point - which is what you are proposing with at.

Does that make more sense? If it still sounds automatic, I haven't explained it well. :)

@scottkellum
Copy link
Author

scottkellum commented Dec 25, 2012

2 to 4 of (2 4 6 8 6 2) — this language feels more like isolation.

I am most worried now that we have far too many different styles of defining location on the table now with 2nd, at, and to. Semantically I don’t see the difference between 2nd and at 2 and still think we should choose between one of the two, I am leaning towards at. If you see differences between these two I think they need to be VERY carefully documented.

I think I know what the confusion is. It seems like you are thinking of non-uniform grids as using a different syntax from non-uniform grids while I am trying to find a unified syntax. I am pretty worried about having two different syntaxes for both types. Would love to just add a location to support non-uniform instead of having a completely different 2 to 4 style syntax.

@mirisuzanne
Copy link

mirisuzanne commented Dec 26, 2012

Sorry, maybe I don't understand all the categories. What is a uniform asymmetric grid, as opposed to a non-uniform one?

@scottkellum
Copy link
Author

scottkellum commented Dec 26, 2012

Sorry, not keeping my language consistent. “uniform” = “symetric” and “non-uniform” = “asymmetric”. Uniform and non-uniform are a little more specific. That language was pretty bad and confusing, fixed now.

@Snugug
Copy link

Snugug commented Dec 26, 2012

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:

  • Symmetric Float: With a symmetric float output where which column on the gird is irrelevant, at very easily can mean push/pull (although span(3 at -1) seems a bit odd to me). span(3 at 2) sounds like it could be a push.
  • Asymmetric Float: Here it gets complicated. We need a way to specify both which column on the grid to use and a way to push/pull. Because we are using float output and not isolation output, we don't have the positioned margins to rely upon, so we need a way to do both separately. In this instance, at more easily portrays column on grid and push/pull more easily portrays positioning.
  • Symmetric Isolation: Symmetric grids with isolation output are interesting to deal with. On one hand, you don't need need which column on grid in order to effectively size an element. On the other, you do need it for positioning due to how the system works. With that said, I believe that this could work similarly to symmetric float.
  • Asymmetric Isolation: The kicker (for the time being). Because you again need to be able to determine both position and column on grid, we're left in the same position as asymmetric float of needing to have two different syntaxes to effectively do this (why you would push/pull an asymmetric grid's columns on itself is a different question though).

Hopefully that's clear and shows a clear need for both at and push/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, while at 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 with using float.
  • '$gutters`: The default gutter options, mostly for convenience.
  • $border-box: Boolean. Include box-sizing: border-box on all grid items or not. Could be overridden with with border-box or without border-box.
  • $clearfix: Boolean. Include a clearfix on all grid items or not. Could be overridden with with clearfix or without 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:

  • Things Cannot Be Made Harder If something is currently easy to do, say defining responsive grid sets, it cannot be made harder or omitted in the new system. It may be different, but it cannot be harder, at least not significantly so.
  • Plan For The Future A fluid grid is fundamentally easy: give me X pieces that are in Y proportion to the whole. We should only make assumptions based on that. Anything else, from moving around the grid to how it should be output to whether to include things like border-box or clearfix 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.
  • Encourage Good Habits While we cannot force users to use ems for container widths or build mobile first, the code and documentation we write should all reflect good habits and best practices and we should actively discourage bad practices. This includes encouraging off the bat responsive web design, being future friendly, mobile first development, and fluid grids. We can provide the tools to build using good habits based on a user's current knowledge level, say being able to convert 300px 600px 250px 300px into a 3 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 of 12 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!

@scottkellum
Copy link
Author

scottkellum commented Dec 26, 2012

Just popping in to say I wrote a quick function that can make some natural language parsing work pretty well: https://github.com/ericam/susy/blob/susy2_math-engine/sass/susy/_math.scss#L24

Still issues with identifying the unperfected span number in code. Would love to think about this stuff without worrying about how it can be parsed, I’m sure we can make something work and user-facing stuff seems most important. But Susy is an interface for math and there is a lot of code we should be thinking about now.

+1 @Snugug on other points.

@mirisuzanne
Copy link

mirisuzanne commented Dec 28, 2012

Agreed on all counts, with some questions still remaining :). Great write-up @Snugug. @scottkellum, I'll have to play with that function to understand it better, but it looks sweet. Thanks!

I agree that we should always allow as much as possible, while pushing best-practice defaults. The current defaults are a legacy problem, not a decision to push desktop-first approach. I'm also certain we will need at least most of the global settings mentioned, and possibly a few more. Mainly I'm interested in determining each feature we need to handle, and then the best way to handle it at each level (local & global) as needed. I think we're on track for that.

I don't think anyone has proposed that float/isolate should be automatic. We all agree that output should be explicit in every way. It's just a matter of nailing down how each feature is stated.

As I understand, here are the arguments that we need (and some proposals for how they might work):

  • Arbitrary width: 30% or 30em or 300px (easy!)
  • Uniform column span, with optional context: 3 or 3 of 6
  • Non-uniform column span, with location-select and optional context: 3 at 3 or 3 at 4 of 12
  • Pushing & pulling: push 4 or pull 3
  • Isolated location: isolate 4

More on isolation:

Isolation is not an entirely distinct grid output type, it's simply a way of moving your columns around. It is the "absolute" alternative to the more "relative" push/pull. It's a local decision, not a global one. Here's two reasons:

  1. Since isolation requires an extra argument on each element anyway, I don't see any reason for a global setting. If the argument is passed, you want isolation, if it isn't, you want floats. That's not automatic, it's explicitly called with it's own syntax:
$output: isolate;

// this is required either way (with or without the global setting), and works fine without it.
// the global setting has accomplished absolutely nothing.
.thing { @include span(3 isolate 4); }
  1. It's bad for the flow, requires extra markup & css, and is basically a hack. We should not be pushing this as a global setting - we should be pushing it as an option you use in the few cases where it really can help.

More on non-uniform location-selection (which column widths to use):

I'm not entirely convinced that <span> at <location> is the best syntax for working with non-uniform grids. I was never suggesting that we use at for both location and isolation - only that I think it works better as an isolation syntax than it does as a location syntax. To me, it seems strange to define non-uniform spans based on their count and starting-point. We don't actually care how many are spanned (and neither does the user) - what matters is where we start and where we end. Why not base the syntax on start and finish, rather than start and count? We could use <start> to <end>?

// Say we want to span columns 4-7 (3 columns) of a non-uniform 12-column grid

// your proposed syntax takes start (4) and count (3):
.thing { @include span(3 at 4); }

// my syntax doesn't care how many - only where we start (4) and where we end (7):
.thing { @include span(4 to 7); }

@Snugug
Copy link

Snugug commented Jan 2, 2013

I think we should decouple the idea of isolation and float. The reason I suggest that they are global settings is because:

  1. We are not just dealing with float vs isolation, we want this system to eventually be able to do CSS grids, tables, etc…
  2. Some people (like John and many Gridset users) will want to use Isolation for all of their items. It's a grid output style like any grid output style. I think we should keep it simply like that.

@Snugug
Copy link

Snugug commented Jan 2, 2013

I think we should decouple the idea of isolation and float. The reason I suggest that they are global settings is because:

  1. We are not just dealing with float vs isolation, we want this system to eventually be able to do CSS grids, tables, etc…
  2. Some people (like John and many Gridset users) will want to use Isolation for all of their items. It's a grid output style like any grid output style. I think we should keep it simply like that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment