-
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
Gridsets #22
Comments
Not sure how this isn’t already implemented. The layout can be adjusted or re-written in full anywhere in the cascade. |
Really? Guess I just haven't played around with it to see how it works quite yet. |
Yup, no info is stored and the grid is calculated with each mixin/funciton. Each new var will override previous vars. |
Hmm, that could get messy to keep everything together. If I had three different layouts, I would my variables for each MQ whenever I write, so I would need to do something like this: $columns: 4;
$bkpt: 500px
#foo {
@include grid-span(3, 1);
@include breakpoint($bkpt) {
$columns: ratio(4/3, 5);
@include grid-span(2, 1);
}
$columns: 4;
}
#bar {
@include grid-span(1, 3);
@include breakpoint($bkpt) {
$columns: ratio(4/3, 5);
@include grid-span(3, 2);
}
$columns: 4;
} If so, that gets unweildy super duper quick and may actually do weird things to the column counting. |
$columns: 4;
$bkpt: 500px
#foo {
@include grid-span(3, 1);
@include breakpoint($bkpt) {
@include grid-span(2, 1, ratio(4/3, 5));
}
}
#bar {
@include grid-span(1, 3);
@include breakpoint($bkpt) {
@include grid-span(3, 2, ratio(4/3, 5));
}
} better? |
Still not very dry. I think I've got an idea how we can make this more user friendly using the Breakpoint Context stuff I just wrote. We'll talk Tuesday if you're not too exhausted. |
Curious as to how this can get DRY-er. Having a dependency on breakpoint bothers me for syntax reasons. But if it enhances instead of changing current behavior it should be fine. |
What syntax reasons? And I think it'll enhance the usability of Singularity greatly. |
I want Singularity to be accessible for people who want to use the native |
You can 100% do that with or without Breakpoint |
I'm thinking something like this (yes I'm about to write Sass pseudocode): $gridsets: 1 623px, compound(3, 4) 800px, ratio(1.618, 4)
=grid-span($span, $position)
$min-width: breakpoint-get-context('min-width')
@if $min-width < nth(nth($gridsets, 1), 2)
width: grid-span($span, $position, nth(nth($gridsets, 1), 1)
@else if $min-width < nth(nth($gridsets, 2), 2)
width: grid-span($span, $position, nth(nth($gridsets, 2), 1)
@else
width: grid-span($span, $position, nth($gridsets, 3)
float: left
margin-right: $gutter Something rough like that. I also think, now that I'm writing out something that uses both, that calling the mixin and function the same thing may get confusing. |
I really like the idea of grid sets. lets do it. I want to see this logic abstracted into another mixnin/function to sort out what gridset should be included. That way it can be easily plugged into the object generator mixins as easily as the grid span mixin and maintained independently. |
Ooh. I really like them grid sets too. |
Awesomesauce, and now that Breakpoint 1.1 is out, we can do this! This was my usecase for Breakpoint Context. Okay, so how do we want to see this happen? This is the syntax I'm thinking of, but I don't really like it, so suggestions welcome: // Gridsets are defined as follows:
// default grid, grid1 (min or max width), grid2 (min or max width), etc…
// We will decide if they are min/max width based on whether the sizes are increasing or decreasing.
// We will set $breakpoint-default-feature accordingly
// The following would set up 4 grid breakpoints, a one column grid, a three column grid, a compound 3/4 grid, and a 1.618 5 step grid. The first example sets up the gridsets mobile first, and keeps $breakpoint-default-feature: 'min-width'. The second example would set up the gridsets desktop first, and change to $breakpoint-default-feature: 'max-width'.
$gridsets: 1, 3 445px, compound(3, 4) 792px, ratio(1.618, 5) 900px;
// -or -
$gridsets: ratio(1.618, 5), compound(3, 4) 900px, 3 792px, 1 445px;
// To call a gridset span, something like the following, but I'm not a huge fan
@include gridset-span($span-list);
// A span list would look something like this
$foo-gridsets: 1 1, 2 1, 2 1, 3 2;
#foo {
@include breakpoint(760px) {
@include gridset-span($foo-gridsets);
}
}
// This would be equal to writing
#foo {
@include breakpoint(760px) {
@include grid-span(2, 1);
}
} Thoughts? |
I would prefer to keep the grid syntax the same supporting padding within the multi-dimensional list. Annoyingly we only have two dimensions to work with. meaning parenthesis need to be used to nest lists. Also, I know breakpoint is awesome but for the purposes of this can we adhere to the standard CSS syntax when discussing and implementing this? Trying to keep the learning curve as shallow as possible. $gridsets: 1, (1, 3 1em, 1) 20em, compound(3, 4) 30em; if 3 things in space seperated list the second is gutters: $gridsets: (1, 3 1em, 1) 2% 20em; if 4 things in space seperated list the third is padding: $gridsets: (1, 3 1em, 1) 2% .5em 20em; Slightly annoying, but allows all features to be called with a single list. In order to implement this properly, we need a grid-sorting function that can be plugged directly into the other functions with room for manual override. All the grid sorting function needs to do is identify the context of the function/mixin and write the Ideally implement this should just mean dropping the function in at the top of each grid function/mixin. |
So the syntax we're looking at would be something like the following: $gridsets: ($grid) $min-size $gutter $padding, ($grid) $min-size $gutter $padding, etc… I think that'll get really sloppy really quick, and make it neigh impossible to sight read. Maybe we do something like follows: $gridset: ($grid) $min-size, ($grid) $min-size, etc…);
$gutterset: 2%, 4%, etc… // If there are less gutters than grids, the last gutter carries through
$paddingset: .5em, 2.3em, etc… // If there are less paddings than grids, the last padding carries through I think this creates an easier to read and grok syntax even at the expense of not being able to call it all from within one line. It's a limitation to Sass, but I think this is the way to go. Also, I just want to double check now that you're not as sleepy as you were last night; you're OK with me going forward with this using Breakpoint, right? |
My only concern is that the gutter and padding aren’t directly grouped with the corresponding breakpoint. Yeah, moving forward with breakpoint. |
I agree that that's a concern, but I'm more concerned with the overly verbose single line syntax. I guess we need to decide what's the best option: a coupled solution that's hard to sight read and gets complicated really quick, or a decoupled solution that's easier to sight read by removes a direct tie. For me, I prefer the second solution, especially as there's precedence for it already by having |
Closing this because it was merged in here! |
Reopening. I think this can be tightened up. Breaking some of this out and modularizing it here in the gridsets-modularized branch: |
What if I want to add portrait/landscape to my grids? |
A third argument that assumes portrait?
Although, the issue with this is that users would need to know to write their media queries with orientation as well. This starts to walk the line of wanting Sass to be runtime not compiletime, and may confuse that more. |
So I just talked to a few developers and what everyone basically said is, if they put in landscape, they expect that to work at runtime. This presents a problem for us because our Sass isn't runtime. We could be super crazy smart about it, but it would produce unexpected, bloated, and potentially broken results if we do so. Here's the issue as I see it:
If I have those grids, I would need to write the following for my initial media query, and doing so would break the styling for no-mq browsers #foo {
@include breakpoint(orientation: portrait) {
@include grid-span(2, 1);
}
@include breakpoint(orientation: landscape) {
@include grid-span(3, 1);
}
} If, on the other hand, we assume we're only looking for the orientation MQ with #foo {
@include grid-span(2, 1);
@include breakpoint(orientation: landscape) {
@include grid-span(3, 1);
}
} I'm cool with this, and it solves the first issue, but it means that A) a user would need to know that they need to include the orientation MQ for landscape, and we would assume portrait (this could be a default we toggle, just assuming for now), and they would need to know that their landscape MQ would need to not only provide all of the new stuff for that layout, but would also need to provide all of the overrides for what's not wanted. This is doable, but not ideal IMO. I don't like either. If you have a way you prefer, let me know and I'll code it in. That being said, I'm curious as to a usecase for this, and why orientation would matter for a grid system. |
Maybe making it dumber and being explicit might produce better results. If a breakpoint exactly equals a width, orientation, or ratio in the grid list then it matches, if not assume the no-breakpoint grid or pull the latest standalone grid if one is defined. |
Working on integration into main |
Finally closing this now that its fully integrated! |
@Snugug Dude, beautiful code on this |
A bit far off, but the ability to have different grids at different breakpoints would be awesome. We're going to need to think long and hard about the DX for this though.
The text was updated successfully, but these errors were encountered: