Better compound grid calculations above 2 grids about singularity HOT 21 CLOSED

Moved to a feature request. Scope scaled back to only compounding two grids for now.

from singularity.

I'll take a look at this and see if I can figure out X compound grids.

from singularity.

So here's my new proposed syntax:

$columns: 4, 6, 8, 'compound';

// 1 column span, 2nd position, 1st grid (4);
#foo {
  @include grid-span(1, 2, $compound-grid: 1);
}

// 2 column span, 3nd position, 2nd grid (6);
#bar {
  @include grid-span(2, 3, $compound-grid: 2);
}

// 2 column span, 2nd position, 3rd grid (8);
#baz {
  @include grid-span(2, 2, $compound-grid: 3);
}

I like this for a few reasons: First, instead of creating a new grid, it allows for literal overlaying of grids together (which, as far as I can tell, is the point of compound grids). Second, it can be used with gridsets and isn't such a departure from the way we do grid-span already. Third, assuming I've dotted all of my Is and crossed all of my Ts, non compound grids should remain the same. Fourth, it produces bitchin background grids (Seriously! Check out the background grids it makes!) Fifth, and finally, it in theory allows us to compound any grids together we so choose, including symmetric and asymmetric grids (although the float clearing is a bit wonky on first test, but if we like this I'll figure out what's up there).

Disadvantages to this method as opposed creating a new grid (which we previously did): Gutters don't necessarily line up between grids which is potentially especially bad for even/odd compounding, it's potentially confusing and certainly more complicated than creating a new grid, because physical grids can change, it requires a location (in fact, the more I'm playing with this, especially with anything beyond simply walking across a row, the more I think we should require location in grid-span).

What are your thoughts? Here's the branch

from singularity.

This seems a little verbose and touches a lot of core functionality. I also worry the grid-span mixin is doing too much.

In reality, you can easily create a compound grid by simply having two grids working together at the same breakpoint. Nothing extra needs to be done. However I really like the simplicity of merging grids down to one list that can be

Another issue I have is that compound grids MUST have the same gutter. Maybe variable gutters are something we can add at some point but it is also something I really want to steer clear of as it makes designs wonky and difficult to deal with. If someone wants irregular gutters they can offset them with irregular padding or zero out gutters and just use columns (like in the CSS grid layout spec).

Personally I much prefer the simplicity of the original function and it is already pretty close. I have something floating around in my head that might lock down the algorithm.

One of the core goals of Singularity is extensibility and IMO the core needs to be as simple and concise as possible while grid functions do the heavy lifting. In the short run it might be annoying as we are trying to rapidly ramp up the feature set but it will be far easier to maintain and extend as we grow.

from singularity.

Agreed this is a little verbose, but without knowing more about how you were actually combining them in your function, and not finding any maths, this is what made most sense to me. This is really what I wanted to talk to you about tonight because everything I've read about compound grids is about using two+ grids overlapping instead of creating a new grid out of multiple smaller grids. I simply don't know enough about compound grids to know which take is more accurate and, more importantly, which is more useful.

All of the grids in this solution have the same gutters; the issue is actually that if major grid points don't match up, neither will their gutters. That, however, seems to be an issue inherit in compound grids where grids are overlaid.

I agree on the extensibility, in fact if it weren't so modularized this would have been a lot heavier. I just couldn't see a way of doing how I see compound grids being used without "hacking core" so to speak, but like I said, this is my take based on my knowledge, and you've had more experience w/it than I have.

from singularity.

Yeah we need to go over this in person. Lots of weird maths to go through. I actually had to step away from my computer and pull out some paper to figure out the original compound function.

from singularity.

Haha, yah. Let's defiantly talk tonight.

from singularity.

So after thinking this over a little bit, this is what I think:

I think that our two methods actually represent two different usecases; one, your method, is creating a new grid based on the intersections of other grids, and two, my method, actually overlays the grids so no new grid is created. I'd actually argue that both of these are valid usecases and we should support both. Either, I believe, will require us to make some modifications to the grid-span mixin, but I'm OK with that because we kinda need to for either case.

I've got some time while we're getting me set up for me to work on Singularity and I'm happy to knock out a bunch of these tickets while I've got the time, including this and fully integrating gridsets. Let me know what you think and I'll jump on it.

from singularity.

Yeah, really wish I had some time to dive in here as I have some pretty strong opinions. Unfortunately have no time to give much direction either. :(

from singularity.

:/ Okay. Well if you get some time to write out a direction or put something into words, do let me know. I wanna work on this, but I want to do it collaboratively. I'll hold off until you can come up for a bit of air.

On Wednesday, September 5, 2012 at 4:28 PM, Scott Kellum wrote:

Yeah, really wish I had some time to dive in here as I have some pretty strong opinions. Unfortunately have no time to give much direction either. :(

—
Reply to this email directly or view it on GitHub (https://github.com/scottkellum/Singularity/issues/7#issuecomment-8312718).

from singularity.

Yeah, I know it sucks. #21 is all yours and still a lot to do with #22. Would really love to see grids isolated and working with generic mixins.

from singularity.

Yah, I'll take a look at those and get them up and rocking.

from singularity.

making progress here: scottkellum/singularity@eac10c0

A little rusty, warming up with this.

from singularity.

Welcome back!

I've got a question for you; it does seem like the approach you're taking and the approach I took, while both fall under the "compound grid" moniker, have two different usecases; yours is for creating a new grid, mine is for layering grids. Thoughts on including both? I think the big difference is the ability to layer asymmetric grids as opposed to only symmetric grids.

from singularity.

yeah lets do it, know of any use cases for layering asymmetric grids? Seems like if you are building asymmetric grids you already know exactly what the end result will be.

possibly at inbetween break points where some things can snap up to a new grid while some things remain.

Maybe merging a modular scale grid + uniform grid?

want to make sure it has a solid use case before adding the extra complexity. If it is the later use case only it might be easier to write that into a function.

from singularity.

Might be able to add non uniform support to the new compound grid function.

$grid: compound(2 (2 3 4) 5);

note the center list, (2 3 4) is the asymmetric grid.

The new function sets up a base resolution similar to what we do for other asymmetric grid math. The resolution for the asymmetric grid would have to be passed through as the uniform column value, then each # in the grid would need to be divided by the resolution and switched out when a column is written.

from singularity.

Couldn't we keep the more intuitive comma separated list by using @mixin compound($grids...)? Just about the only case I can really think of where this makes sense.

On Oct 20, 2012, at 9:29 AM, Scott Kellum [email protected] wrote:

Might be able to add non uniform support to the new compound grid function.

$grid: compound(2 (2 3 4) 5);
note the center list, (2 3 4) is the asymmetric grid.

The new function sets up a base resolution similar to what we do for other asymmetric grid math. The resolution for the asymmetric grid would have to be passed through as the uniform column value, then each # in the grid would need to be divided by the resolution and switched out when a column is written.

—
Reply to this email directly or view it on GitHub.

from singularity.

Wish we could have N arguments passed through mixins/funcitons. Requiring vars passed through or parenthesis passed through adds complexity as well.

This function doesn’t care how the list is being separated, so passing comma separated values through a var should work just fine.

$grids: 2, 3, 5
$grid: compound($grids);

// or

$grid: compound((2, 3, 5));

asymmetric grids like the ex above are already wrapped in parenthesis so, yes, easy to have commas separating that list.

from singularity.

I can also restrict the number of grids to something like a max of 10 compounded grids. That way we would be using traditional function arguments instead of lists.

from singularity.

OK, syntax back to compound(2, 3, 5) with a max of 16 arguments

from singularity.

I think we can close this, no?

from singularity.