Skip to content
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

Closed
Snugug opened this issue Jul 26, 2012 · 27 comments
Closed

Gridsets #22

Snugug opened this issue Jul 26, 2012 · 27 comments

Comments

@Snugug
Copy link
Member

Snugug commented Jul 26, 2012

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.

@scottkellum
Copy link
Member

Not sure how this isn’t already implemented. The layout can be adjusted or re-written in full anywhere in the cascade.

@Snugug
Copy link
Member Author

Snugug commented Jul 26, 2012

Really? Guess I just haven't played around with it to see how it works quite yet.

@scottkellum
Copy link
Member

Yup, no info is stored and the grid is calculated with each mixin/funciton. Each new var will override previous vars.

@Snugug
Copy link
Member Author

Snugug commented Jul 26, 2012

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.

@Snugug Snugug reopened this Jul 26, 2012
@scottkellum
Copy link
Member

$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?

@Snugug
Copy link
Member Author

Snugug commented Jul 27, 2012

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.

@scottkellum
Copy link
Member

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.

@Snugug
Copy link
Member Author

Snugug commented Jul 27, 2012

What syntax reasons? And I think it'll enhance the usability of Singularity greatly.

@scottkellum
Copy link
Member

I want Singularity to be accessible for people who want to use the native @media (min-width: $whatever) syntax.

@Snugug
Copy link
Member Author

Snugug commented Jul 27, 2012

You can 100% do that with or without Breakpoint

@Snugug
Copy link
Member Author

Snugug commented Jul 27, 2012

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.

@scottkellum
Copy link
Member

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.

@codingdesigner
Copy link
Member

Ooh. I really like them grid sets too.

@Snugug
Copy link
Member Author

Snugug commented Jul 30, 2012

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?

@scottkellum
Copy link
Member

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 $columns, $gutter, $padding unless these values have already been explicitly defined.

Ideally implement this should just mean dropping the function in at the top of each grid function/mixin.

@Snugug
Copy link
Member Author

Snugug commented Aug 1, 2012

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?

@scottkellum
Copy link
Member

My only concern is that the gutter and padding aren’t directly grouped with the corresponding breakpoint.

Yeah, moving forward with breakpoint.

@Snugug
Copy link
Member Author

Snugug commented Aug 2, 2012

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 $columns, $padding, and $gutter as separate variables. In fact, maybe the answer to $gridsets is simply to extend the functionality of these existing variables, allowing $columns to take either a single column, or a list of columns and min-widths, allowing $padding to take a single padding, or a list of paddings, and allowing $gutter to take a single gutter or a list of gutters.

@Snugug
Copy link
Member Author

Snugug commented Aug 5, 2012

Closing this because it was merged in here!

@Snugug Snugug closed this as completed Aug 5, 2012
@scottkellum scottkellum reopened this Aug 5, 2012
@scottkellum
Copy link
Member

Reopening. I think this can be tightened up. Breaking some of this out and modularizing it here in the gridsets-modularized branch:
scottkellum/singularity@1d9b8f3

@scottkellum
Copy link
Member

What if I want to add portrait/landscape to my grids?

@Snugug
Copy link
Member Author

Snugug commented Sep 5, 2012

A third argument that assumes portrait?

$grids: 3, 4 landscape, 10 500px, 15 500px landscape;?

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.

@Snugug
Copy link
Member Author

Snugug commented Sep 6, 2012

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:

$grids: 3, 4 landscape, 10 500px, 15 500px landscape;

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 breakpoint-context, we could write the following:

#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.

@scottkellum
Copy link
Member

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.

@Snugug
Copy link
Member Author

Snugug commented Sep 20, 2012

Working on integration into main +grid-span here:
https://github.com/scottkellum/Singularity/tree/grids-integration

@Snugug Snugug closed this as completed Sep 28, 2012
@Snugug
Copy link
Member Author

Snugug commented Sep 28, 2012

Finally closing this now that its fully integrated!

@scottkellum
Copy link
Member

@Snugug Dude, beautiful code on this

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

No branches or pull requests

3 participants