-
Notifications
You must be signed in to change notification settings - Fork 109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better compound grid calculations above 2 grids #7
Comments
Moved to a feature request. Scope scaled back to only compounding two grids for now. |
I'll take a look at this and see if I can figure out X compound grids. |
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 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 What are your thoughts? Here's the branch |
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. |
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. |
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. |
Haha, yah. Let's defiantly talk tonight. |
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 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. |
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. :( |
:/ 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:
|
Yah, I'll take a look at those and get them up and rocking. |
making progress here: scottkellum/singularity@eac10c0 A little rusty, warming up with this. |
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. |
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. |
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, 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. |
Couldn't we keep the more intuitive comma separated list by using On Oct 20, 2012, at 9:29 AM, Scott Kellum notifications@github.com wrote:
|
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. |
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. |
OK, syntax back to compound(2, 3, 5) with a max of 16 arguments |
I think we can close this, no? |
Compound grid math above 2 grids isn’t very accurate yet. Needs work.
The text was updated successfully, but these errors were encountered: