foundation-sites 🚀 - [Foundation Future] Discussion on Grid's Future ( Flex/Float/Spec - Margin/Padding )

https://rachelandrew.co.uk/archives/2016/03/30/should-i-use-grid-or-flexbox/

This is how flexbox works. However, most of the flexbox problems I am asked about are due to developers trying to make flexbox do layout in two dimensions. This is where you need Grid Layout.

IamManchanda on 14 Mar 2017

👍1

The prevailing advice seems to be to not co-opt CSS Grid into frameworks like this (emphasis mine):

I know a lot of people will think the “best” way to use CSS Grid will be to download the new version of Bootstrap (version 5! now with Grid!), or to use any one of a number of CSS Grid layout frameworks that people are inevitably going to make later this year (despite Rachel Andrew and I begging everyone not to). But I don’t. The more I use CSS Grid, the more convinced I am that there is no benefit to be had by adding a layer of abstraction over it. CSS Grid is the layout framework. Baked right into the browser.

— http://jensimmons.com/post/feb-28-2017/benefits-learning-how-code-layouts-css

It's worth remembering the obstacles that have been encountered in trying to create a flexbox system that handles all of its options. Grid is way more intricate – it would be more difficult to create a class-based system than just advising users to use Grid itself.

orangedaisy on 15 Mar 2017

👍4

@orangedaisy very good point. Grid should really be used as the base layout for a page and inside this grid rows and columns from foundation can work very nice. Even with flexbox I'm not sure if there is any need for grids anymore. There are a lot of flexbox features that are very hard to put into css-classes by using foundation-flexbox grid it's only possible to use a very small part of flexbox.

The most important thing is, that flexbox and css-grid solve different layout needs. So they should be used in combination not like flexbox mode at the moment.

DaSchTour on 15 Mar 2017

The most important thing is, that flexbox and css-grid solve different layout needs. So they should be used in combination not like flexbox mode at the moment

@DaSchTour :+1: :+1: :+1: :+1: ....... A trillion :+1:

One dimensional Layout => Flexbox
Two dimensional Layout => CSS Grids

Grid is way more intricate – it would be more difficult to create a class-based system than just advising users to use Grid itself.

@orangedaisy We are talking advanced layouts here, we should not create classes for everything, Infact there are so many properties, there is no way we can create classes for everything,
I feels Sass Mixins are the best way to go about.
For example,

@include grid-wrapper (
  $row : 100px 1fr auto,
  $column : 1fr 200px,
  $gap: 10px 20px,
  $align: center,
  $justify: space-evenly,
  $areas: "header  header"
          "content aside "
          "footer  aside ",
);

@include grid-row (1/3);
@include grid-column (2/4);

IamManchanda on 15 Mar 2017

Tagging you @corysimmons because Looking at this Feature Queries example by mozilla,

I have got one deep question in mind,
Can there be a combo of something like { Calc Grids + Feature Queries + CSS Grids }

IamManchanda on 15 Mar 2017

@IamManchanda Creating mixins like this is, I'm sorry to say, a fool's errand. You're just recreating the browser's built-in functionality. How is that helpful?

orangedaisy on 15 Mar 2017

@orangedaisy ohk so what's best way out according to you ?

IamManchanda on 15 Mar 2017

@IamManchanda The best way is to not do it at all. It doesn't matter what you do – classes, mixins, functions, etc – you're just going to be increasing complexity and recreating something the browser already does. It's like that gradient mixin from a couple of weeks ago: the browser already does this. There's no need to make it more complicated.

orangedaisy on 15 Mar 2017

ohk @orangedaisy

But i have my two cents on it!
Deep down in my head, I have a thing that coming to my mind

Calc Grids + Feature Queries + CSS Grids Spec = Production

So, I will wait for @corysimmons comment for the same

Reason:
https://github.com/corysimmons/postcss-ant#what-about-grid-spec

Fun Fact: Grid Spec's API was developed independently of postcss-ant's. Any similarities with how size setting works (e.g. fixed takes precedence over fr) is completely by coincidence and a testament to how good of an idea these new ideas about sizing are.

IamManchanda on 15 Mar 2017

You _should not_ try to recreate the Grid spec. I don't understand what any of this has to do with Cory's postcss plugin.

orangedaisy on 15 Mar 2017

@orangedaisy coz i have followed his work!!!

https://corysimmons.com/

This site was designed with a golden ratio grid using a PostCSS layout plugin I made that mimics much of CSS Grid Spec but works seamlessly in IE9

IamManchanda on 16 Mar 2017

If you want I can do a grid with a setting so developers serving different audiences can pick and choose based on their needs. For instance, if you don't need centering or equal height, you should use float just for browser support.

$grid-type could take:

float
inline-block
flexbox
grid-layout

I think something that makes my postcss-ant project different is that it makes working with real ratios incredibly easy.

I think it'd be interesting if Foundation migrated to PostCSS. You guys are missing out on so much power vs JavaScript. PostCSS projects also work with any CSS preprocessor, or just vanilla CSS, and compile much faster than other preprocessors.

🍕 for thought.

Anyone else excited about Game of Thrones Season 7?!

corysimmons on 17 Mar 2017

❤1 🎉1 😄1 👍1

Yes excited and two version 7

Game of Thrones Season 7
Foundation for sites 7

If you want I can do a grid with a setting so developers serving different audiences can pick and choose based on their needs. For instance, if you don't need centering or equal height, you should use float just for browser support.

@corysimmons First of all, to let you know, we are dropping IE9 ...

My 2 cents

What maybe great as a fallback to CSS Grids i feel would be Calc combined with feature queries because both have almost similar browser support. Calc | Feature Queries. I feel that these two have good browser support specially considering foundation 7 will be around there about end 2017/early 2018.
Flexbox ofcourse will be there in there about as its FLEXBOX

Yes opera mini and UC browser is a concern though as far as browser support is concerned!

IamManchanda on 17 Mar 2017

I think it'd be interesting if Foundation migrated to PostCSS. You guys are missing out on so much power vs JavaScript. PostCSS projects also work with any CSS preprocessor, or just vanilla CSS, and compile much faster than other preprocessors.

I don't know ...
To be advanced is very important for any framework but i love sass so its hard and emotional for me to comment on.... will tag @kball on answering this !

IamManchanda on 17 Mar 2017

I like Sass too. I use both. Sass for generic syntax help, and PostCSS for heavy-lifting plugins/functions.

Regarding dropping support for IE9, that's fine. I'm a fan of progressive enhancement.

I've worked on sites built completely with flexbox recently. Once you get into browser support testing, you end up spending a lot of time and energy trying to make various flexbug workarounds work together.

So, unless flexbox is offering me something I need (order, easy equal-height columns, alignment with one less element) then I typically fall back to float based layouts (yes... still).

Typically I end up building the big structure of a site using mostly floats, then sprinkle flexbox in where I really need it. During browser testing, hardly anything is outright broken in a huge amount of browsers.

I'm not a luddite. In fact, I would be ecstatic if everyone used latest Chrome, but can you imagine if Google itself didn't support 5% of browsers just because they wanted to use whatever "the CSS hawtness" was at the time?

With a settings-based approach to this problem, you could target audiences very easily. When flexbug-affected browsers were below 1%, you could sunset the float arg. When 99% of browsers supported grid layout, you could sunset flexbox. etc.

Another approach: If ZURB (or any company) is interested, I can make grid layout's API work in IE9+ during the compilation stage (not a JS-dependent polyfill). It'd take a month or two working on it several hours a day so I'd need funding, but I imagine the public would really appreciate being able to use Grid Layout right this second.

corysimmons on 17 Mar 2017

👍1

I should be explicit. When I say "IE9+", I don't mean "We need to support IE9 guys!"

Flexbox is full of bugs and no one seems to care about an old browser user (0.5%?) here and there. But those small percentages of users missing support add up quick and you end up with a broken site for something like 5% of users.

So when I say "IE9+", I'm just pointing out that it'd work in 99.9% of browsers seamlessly.

corysimmons on 17 Mar 2017

👍1

Flexbox is full of bugs and no one seems to care about an old browser user (0.5%?) here and there. But those small percentages of users missing support add up quick and you end up with a broken site for something like 5% of users.

You nailed it but most bugs are only there in flexbox because people wanna use flexbox for two dimensional layouts.

IamManchanda on 22 Mar 2017

People use flexbox for everything. It'd work if there weren't so many bugs, but the bugs _are_ there, and they get worse as you nest and the more things you try to do with it.

I'm speaking from real-world experience walking into a dozen sites that were about to launch. The client reviewed them on Safari (version was less than a year old) and opened dozens of requests to fix various things. As I fixed them, they introduced other bugs in other browsers. This dance took forever.

Flexbox has its place, but the bugs make it nearly unusable for me.

I suspect grid layout will suffer the same fate. Only time will tell.

Hence I'd suggest making what type of grid you're using a setting, and preferably defaulting to float-based (e.g. bulletproof) layouts.

corysimmons on 22 Mar 2017

Poke @kball @rafibomb!

IamManchanda on 4 Apr 2017

Update: When i created this thread ... browser support was mere 6% ( including that ms grid )
22 days and now its 37% .... Now that's a real push!!!!!
( Expect it soon to go 20 more aka when people update Chrome 56)

Concern: IE/Edge, Mobile browsers (Android webview, Opera mini, UC, Samsung)

Source: http://caniuse.com/#feat=css-grid

IamManchanda on 5 Apr 2017

@IamManchanda Microsoft have started work on updating their implementation. (source)

glen-84 on 5 Apr 2017

❤1 🎉1 😄1 👍1

Vendors promise they'll implement a semi-complicated spec correctly before universe heat death. 👍 💯

👋

corysimmons on 5 Apr 2017

😄1

I tend to agree that CSS grid will need to be opt-in for a while, however I think we should make it easy to adopt... We've got a draft of a CSS-grid based version of the base Foundation grid in progress that we'll use as a stopgap for 6.4, but we really should be discussion not if to use grid bot rather what the world will look like when grid is widely enough supported.

Broadly speaking, I think what this is hinting towards is a world where our "grids" are less architectural choices but more componentized, able to be picked and chosen... but I could be wrong.

I think @corysimmons makes a great point that grids (and technology standards such as flexbox, css grid, and some the other new hotness) should be configurable on/off... Our current binary float/flex approach is pretty cludgy, but works well enough for 2 systems. If we imagine 4, 5, or 6 different grid options, what do y'all think this should this look like moving forward?

kball on 17 Apr 2017

If we imagine 4, 5, or 6 different grid options, what do y'all think this should this look like moving forward?

In one word => Bloat

IamManchanda on 17 Apr 2017

👍1

@IamManchanda possibly... but the question I'd ask is... do grid systems need to be as complex and encompassing as they tend to be today, or should we be thinking of grids more like components that can be contained and mixed and matched?

kball on 17 Apr 2017

Output wouldn't be bloat, but asking people to memorize more settings is just cruel.

I still think you guys are in the unique position to force grid layout on vendors so everyone can be done with layout obfuscations forever. I'll rename my 1st born to "Zurb".

corysimmons on 17 Apr 2017

👍3

Sorry but its too early .... for me best solution would be to delay foundation 7 to early-mid 2018 so that the grid gets good browser support and we can implement one solution grid system!
What do you guys think ??

IamManchanda on 17 Apr 2017

Honestly at this point, I'd just make a simple flexbox grid. Maybe spice it up with some ratio-sizing mixin.

People like flexbox. Autoprefixer covers a lot of edge cases. Special work could be done to ensure flexbugs are minimized.

It'd be simple and everyone would love it.

Since every layout mechanism will be completely trashed when Grid Layout is usable (early adopters late 2017, everyoe else mid 2018), it isn't worth bloating the src with some decoupled adapter thing.

Hell, I'd even padding-grid it just so people didn't have to learn margin grids for several months.

Who am I, and what did I do with @corysimmons?!

corysimmons on 17 Apr 2017

👍2

I actually tend to agree for the base case... @brettsmason is working on a simple flexbox grid... Brett is http://codepen.io/brettsmason/pen/RKMbZG the latest example of what you've been playing with?

kball on 17 Apr 2017

👍1

That's the one...

God I hate padding grid markup. Adding bg color to a row: row > cell-with-bg > row > cells

@IamManchanda Can you give me a thumbs up on this comment?

corysimmons on 18 Apr 2017

😄1

@kball @brettsmason I'll make you guys a ratio-sizing mixin thing if I get a chance. Or I could pseudo-code it and you could implement it however you'd like. It'd make your grid unique without ruffling feathers.

corysimmons on 18 Apr 2017

👍1

@kball Sorry for the delay, I'm away at the moment. So to be honest I haven't progressed anything with the grid, mainly due to lack of feedback on stuff so not knowing what direction to take.

I agree with @corysimmons on a lot of what he said. I've been looking into margin based grids recently and like the idea, but not sure how it would go down with users who have been using padding for so long? I think an option to switch between padding or margin would be good, but might make things too complicated. Whatever is the cleanest and easiest for the end user to implement would be my choice.

Id love to properly discuss it and get a feature list agreed so we can move it forward.

brettsmason on 18 Apr 2017

🎉1

Both options suck and always have.

I think a good test of how complicated/hard-to-use a grid is, is to apply various background colors to things—specifically rows.

Here's how I'd do margin: https://codepen.io/corysimmons/pen/eWpVBN
Let me know how you'd do it with padding.

corysimmons on 18 Apr 2017

@corysimmons Yeah that's a lot like a simple CodePen I put together when experimenting with ideas, and I agree is nice. What are your thoughts on including the margin on one side (left)? eg: https://codepen.io/brettsmason/pen/jmWVNe

The main reason being there is no overflow then if the grid is the full width of the browser window.

I'd really like the grid to be based on a simple selection of mixins (current mixins aren't the best in my opinion) that are easy and intuitive to use but flexible too. I came from using Susy, so I guess that would be my inspiration.

You know far more about it though so I'd value your opinion.

brettsmason on 19 Apr 2017

Single-side margins are less flexible than double side, but, yes, they are really clean.

You _need_ to know how many elements are going to go in a row. Here's an example: https://codepen.io/corysimmons/pen/GmoWGr?editors=1100

I've fought to use the single-side gutter for a long time (Jeet, Lost) because it made more sense than doing some weird overhanging negative-margin stuff. But it has a lot of fringe cases (masonry, breaking if you need to change a one-off item, etc.).

With double-sided gutters you can plop anything anywhere and it'll JustWork™. In Lost and postcss-ant—which really is the pinnacle of losing everything to my obsession with this stuff—I offered both approaches.

But honestly, I think it adds too much stuff for people to remember, especially for a framework like Foundation, so I'd simplify and just keep negative-margin/double-gutter grids in all cases.

Single margin is great for nesting, and double is great for flexibility. Again, no good solution (trust me I've obsessed with this for years) and we should force Grid Layout down peoples' throats and be done with this horrible problem once and for all.

Btw, I'm still interested in a CodePen of how you'd apply a background color to a row, and a different background color to columns, using a padding approach though.

corysimmons on 19 Apr 2017

Thanks, that's helpful and I hadn't thought about things like Masonry use etc. Sounds like double-sided should be what we stick with on that front.

In terms of background colour for rows/columns - the only way is with extra markup as far as I know, eg https://codepen.io/brettsmason/pen/ZKQKEZ

What would you say are the negatives of using a margin based approach? I'm sold on it, but just want to make sure everything is covered.

brettsmason on 19 Apr 2017

Add body { padding: 30px; }. Notice the springgreen overhanging (i.e. not flush with cells as expected).

Negatives of dub-guts (what I'm calling them now because it sounds like a cool zombie name) are it does some negative-margin stuff which can cause overhang issues, but the worst thing is nesting. You did it in your codepen (nesting a cell, just to nest a row).

I've found people don't do a _ton_ of nesting so it's less of an issue than I've made it out to be, but it still sucks when single-gut grids can nest w/o extra markup like so:

<div class="grid">
  <div class="cell grid">
    <div class="cell">1</div>
    <div class="cell">2</div>
  </div>

  <div class="cell">
    3
  </div>
</div>

Pros and cons to everything, which is why I threw my hands up and just began offering everything. :(

Grid Layout solves all this crap.

corysimmons on 19 Apr 2017

Ah OK great - I see the problem with that now 👍

My main aim would be to get rid of the madness that is the current nested, overly specific classes, and get away from things like this: https://github.com/zurb/foundation-sites/issues/995

@kball @rafibomb what do you think? I guess it could potentially be a breaking change, but we have never shied away from moving things forward.

I'd propose that for 6.4 we completely rework the flex grid to be a margin based grid and ditch padding. I've already done a lot of the work, but I'd need a decision on if this would be OK?

Grid layout looks great, but unfortunately for people like me who wont be able to use it in my every day work, it wont really solve anything for now.

brettsmason on 19 Apr 2017

Grid layout looks great, but unfortunately for people like me who wont be able to use it in my every day work, it wont really solve anything for now.

Fair enough, and tbh, Foundation probably shouldn't even abstract Grid Layout's API.

To do the margin stuff, you'd need some control over gutter on a global, and per-row basis, via a mixin.

corysimmons on 19 Apr 2017

Yeah agreed - I think people should be encouraged to learn the API, no need to get involved 👍
I'll get together what I've done so far and get it online somewhere for you to see, assuming its given the go ahead.

brettsmason on 19 Apr 2017

👍1

@brettsmason I'm down with breaking change, but prefer we go through a deprecation cycle to do it, so that we don't completely block folks who want to upgrade but need more time.
A tentative proposal would look something like this:

We create the new margin-based flex grid as an independent mixin using a 'zf-' namespace (we want to move all of our SCSS to namespacing anyway)
We make the new grid the default (we want to make Flex the default anyway, this would really jump us forward)
We write a migration guide (how to move from old flex grid to the new grid)
We provide a way for someone to opt back to the old flex grid with a deprecation warning that it will be dropped in 6.5.

Thoughts?

kball on 19 Apr 2017

👍1

@kball ok thanks, I think that makes sense.

And what about the margin based approach? Foundation has always used padding so it would be a fairly big shift.

brettsmason on 19 Apr 2017

Yes fairly big shift but that's ohk with an Avanced and bold framework like foundation!

IamManchanda on 19 Apr 2017

As mentioned above - big shifts are fine with me if they move us in the right direction and we give folks a path and adjustment period.

That said, I'd be interested in some of the opinions of more SCSS & design focused folks like @gakimball @tdhartwick @jnemeth @andycochran @ncoden

kball on 19 Apr 2017

👍1

Question for everyone. Is there still value in the responsive gutter stuff? I've never used it myself so interested if its worth keeping. It adds a lot of bloat and (in my opinion) not needed complexity.

I'm busy working on putting something together at the moment for this!

brettsmason on 20 Apr 2017

I think responsive gutters are definitely useful.

Off the top of my head, the syntax could look like:

$zf-column-gutter: 60px;
$zf-row-gutter: 30px;

.default-grid {
  @include zf-grid(1/4);

  @media (min-width: 800px) {
      @include zf-grid(1/4, $column-gutter: 10px); // should usually only need to be applied to the container
  }

  .big-cell {
    @include zf-cell(1/2);
  }
}

.one-off-size {
  @include zf-cell(2.5/6, $column-gutter: 30px, $row-gutter: 2%);
}

I don't think responsive gutters should be the default dist. But the generator should offer this kind of functionality in a dynamic way.

I've made a billion PoC of this kind of stuff, so implementation won't be a problem once we settle on an API. Maybe we should shift the discussion to designing the API first and not worry about complexity?

Irrelevant Sidecry: It sucks so bad that attr data only works with the content property in CSS or we could do some really cool stuff directly from the markup <div columns="1/2" gutter="15px">. It's possible with something like Reshape but that's a pretty big dependency for a project like this.

corysimmons on 20 Apr 2017

Thanks @corysimmons. I think part of the problem is the current grid is just so unnecessarily complicated, where I don't think it needs to be (its hurting my head reading through it all!).

Another issue I've come across with using margin based grids plus calc() is if we include a .collapse class like the current grid to remove margins from columns within a row.

That's maybe more to do with the spaghetti of mixins/functions at the moment though maybe, but I'm not sure how to structure everything to offer a great set of clear functions/mixins to do all we need...

brettsmason on 20 Apr 2017

I completely get that. The overwhelming amount of settings/spaghetti involved with these big CSS frameworks is the reason I, and a lot of other devs, avoid them.

How integrated is the grid stuff with components? If it is, it shouldn't be, and components should be scoped using vanilla flexbox.

The concept of a "grid" has always worked best as a structure/overall-layout thing imo.

If it's not coupled, then just delete all the grid stuff and focus on making a couple really flexible/powerful mixins (zf-grid and zf-cell).

zf-grid would be applied to a container.
zf-cell applied to any one-off sizes.

Write a loop for your base grid classes:

loop over breakpoints
  loop over number of columns

Then just write additional loops for things like .collapse:

// base grid
loop over breakpoints
  loop over number of columns

// .collapse
loop over breakpoints
  loop over number of columns using $gutter: 0

// additional stuff
loop over breakpoints
  loop over number of columns + whatever

This will modularize these loops a bit so they can be switched on/off (for things like the generator), or an internal generator like @include zf-generate-grid($breakpoints-map, $number-of-columns, $include-collapsed, etc.).

corysimmons on 20 Apr 2017

Keep in mind, margin-based grids cause the body to scroll horizontally unless its padding is greater than the negative margin-right of the row. If you want your grid flush with the edges of the page, you need a padding-based grid (or a left side only, single-sided, margin-based grid).

andycochran on 20 Apr 2017

Or body { overflow-x: hidden }

corysimmons on 20 Apr 2017

👍1

@corysimmons Thanks that really helped clear things in my mind.

I wanted to pick your brains on single sided margin grids again if you don't mind, as I like the fact it doesn't cause overflow etc.

I forked a Masonry demo and edited it to use a single sided margin: http://codepen.io/brettsmason/pen/JNXwVq - as far as I can see it works OK, though I will admit I haven't had to use Masonry or an alternative in years.

By the way really interesting reading looking at your other projects (Lost especially)!

@andycochran What do you think of padding vs margin? I'd value your opinion too. I like the fact that with a margin grid, the grid classes could be applied directly to cards for example.

brettsmason on 21 Apr 2017

👍1

I wanted to pick your brains on single sided margin grids again if you don't mind, as I like the fact it doesn't cause overflow etc.

Again, I really think you should avoid single-sided grids. I know how sexy the markup is, but even if you aren't using masonry, users should have an option to plop one-off cells within a container.

If you _do_ go the single-sided route, at the very least I'd offer an escape hatch for the negative-margin grids.

By the way really interesting reading looking at your other projects (Lost especially)!

Lost is nice. It ended the need for the "context" stuff that Susy and Jeet have. It's maintained _really well_ by Peter nowadays. That said, postcss-ant is probably the most interesting thing I've done in the layout space.

What's the team's thoughts about migrating from Sass to PostCSS? Bootstrap is considering it for v5.

It'd make Foundation available to users of any preprocessor, or vanilla CSS, and it's insanely powerful (all the power of JS vs. the subset of functions preprocessors handle).

corysimmons on 21 Apr 2017

Again, I really think you should avoid single-sided grids. I know how sexy the markup is, but even if you aren't using masonry, users should have an option to plop one-off cells within a container.

Stupid question, but what do you mean by the bit in bold? Just want to understand what you mean (example might help), but I totally take on board what your saying so we will go with split, especially as its what users are used to anyway.

In terms of moving to PostCSS - I think it might of been discussed very briefly but not in any detail. I'd be interested to know more about it, as I'll confess to having never used it. From what I understand its more modular in its approach though with additional plugins to handle things that Sass does natively for example.

The Zurb guys like to keep as cutting edge/up to date with advancements as is possible, so I'm sure they would be open to at least discussing what the benefits would be, and what would be involved (I definitely would).

brettsmason on 21 Apr 2017

👍1

@andycochran What do you think of padding vs margin? I'd value your opinion too. I like the fact that with a margin grid, the grid classes could be applied directly to cards for example.

Well I see use cases for each method being "better." But it seems to me like most designs need both.

Margin for spacing multiple things inside containers:

And padding for defining containers that divide space:

Using margin for grid column layout doesn't preclude us from also using padding on those columns. The second example above could be done with margin:0.

andycochran on 21 Apr 2017

👍1

@brettsmason

Stupid question, but what do you mean by the bit in bold? Just want to understand what you mean (example might help)
https://codepen.io/corysimmons/pen/GmoWGr

Basically, single-side grids (or "nth-grids" as I call them) need the CSS to define the number of elements in each row. With double-sided (or "negative-margin", "masonry" grids) you don't need to care about how many elements are in a row as long as they add up to 100% width.

From what I understand its more modular in its approach though with additional plugins to handle things that Sass does natively for example.

Regardless of whatever memes people are spewing about PostCSS, it's biggest benefits are:

Works with ANY preprocessor, OR just vanilla CSS.
All the power of JS whereas preprocessors only give you a handful of functions/logic.

The downsides of PostCSS:

Docs are auto-generated and confusing as hell.
CLI is lacking (i.e. needs a more flexible API).
SugarSS (PostCSS' attempt at replicating the niceties of preprocessors—nestings, vars, etc.—is buggy/lacking.

The best combination, imo, is PostCSS for libs, Sass (Stylus really, but Sass is more popular) for syntactic sugar.

If PostCSS libs are written with preprocessors in mind, you can layer them.

in.scss -> out.css -> PostCSS -> out.posted.css

This gives you the best of both worlds (power of PostCSS, bug-free sugar of Sass), but might be a lot to ask of users. You guys can be the call of that.

@andycochran

Using margin for grid column layout doesn't preclude us from also using padding on those columns. The second example above could be done with margin:0.

This is an important note which makes the argument for padding grids moot.

https://codepen.io/corysimmons/pen/aWZbNB?editors=1100

corysimmons on 21 Apr 2017

👍2 👎1

in.scss -> out.css -> PostCSS -> out.posted.css

Love it!

IamManchanda on 21 Apr 2017

I think we should move PostCSS discussion to another issue, but I think it is definitely worth pursuing - have some ideas related to it as well, but lets move to an independent thread. @corysimmons do you want to start it?

kball on 21 Apr 2017

👍2

So based on all the feedback and comments as well as a discussion with @kball, I've been working on a sort of proof of concept. You can view it here: http://codepen.io/brettsmason/pen/GmZaxv

Basically I think it would be good to be able to offer the choice between a margin or padding grid (with margin as default imo). The code is a bit on the messy side at the moment, but I'd really appreciate everyones thoughts!

If this goes down well I'll try and turn it into a full working example with a complete set of mixins, and any help would be great!

brettsmason on 21 Apr 2017

👍1

@kball https://github.com/zurb/foundation-sites/issues/9980

@brettsmason Pen is broke. I guess you're working on it right now. If you share a pen, care to fork off it immediately after to guarantee the shared one works, and for posterity's sake?

corysimmons on 21 Apr 2017

Sorry fixed now and yes was tinkering, will fork instead!

brettsmason on 21 Apr 2017

👍1

Thanks. :)

Also, can you start putting body { padding: 30px } so we can see where overhangs are happening?

corysimmons on 21 Apr 2017

Done!
At the moment most of the demos have a .grid-container which limits the width to 1200px - would you prefer I got rid of that?

brettsmason on 21 Apr 2017

This max-width is fine, but not necessary for testing purposes.

It looks like you're on the right track now. It seems like you're having fun with it. Do I smell another grid enthusiast?!

A couple things to solidify an approach (and some docs) on:

Setting background color to a flush container. (just a single cell within a container—it'll produce a lot of markup, but should be a good approach to document)
It seems like you've already addressed this, but I'd add an element or two to your demos to ensure widow elements don't go awry (as flex-grow: 1 will do). Basically, don't have your demos have a perfect number of columns per row.

Now, where :poop: gets tricky... Thoughts on vertical sizing? :)

corysimmons on 21 Apr 2017

It looks like you're on the right track now. It seems like you're having fun with it. Do I smell another grid enthusiast?!

Yep! - as @kball will tell you I tend to get pretty heavy into whatever I work on (off canvas was the last thing). I like working on things that I feel could be made a lot better.

Not sure what you mean with 1. - do you just mean add a <div> within the cells and colour those instead or have I misunderstood?

Re vertical sizing - do you mean eg setting the grid to flex-direction: column and how that would work? Almost like the Foundation for Apps grid? So basically the widths become heights...

brettsmason on 21 Apr 2017

👍1

do you just mean add a
within the cells and colour those instead or have I misunderstood

Sure. Experiment with a couple ways to do this and see which one is the easiest to convey to potential users.

Re vertical sizing - do you mean eg setting the grid to flex-direction: column and how that would work? Almost like the Foundation for Apps grid? So basically the widths become heights...

Something like that. I'm not sure of the implementation, but just thinking about sizing vertically as well—like, if I wanted a 500px tall container, and wanted 3 elements in it that were 1/3 with a gutter between them.

It might be silly to implement since Grid Layout will crush whatever we come up with, but it's worth thinking about.

corysimmons on 21 Apr 2017

So I've been working on putting together the mixins this afternoon and it bought up a few questions.

What should a single .column class behave like? For the live flex grid they take up available space and dont stack like the float grid does. My gut feeling is this should be changed so its 100% width without sizing classes applied. We can then offer some .auto classes or something that add the automatic sizing behaviour.

How do you think the vertical grid should work? I interpreted it as something like this: https://codepen.io/brettsmason/pen/wdzmLO
Basically set a modifier class on the grid/row to make the columns go the other way around, so the sizing is applied to the height instead. Does that sound correct/useful/what you had in mind? I think this could basically incorporate the App grid, but I need to investigate that a little more.

brettsmason on 24 Apr 2017

Sorry @brettsmason

I'd like to keep nerding out on this but no one is paying me to. Going to go study some in-demand tech instead.

You seem to be on the right track with all this stuff so I'm not sure how much more help I could be at this point. Try bouncing these ideas off some html/css-centric co-workers to see how they _feel_ about using your solutions.

I wouldn't worry too much about the vertical stuff if there isn't an elegant solution.

Best of luck. 👍

corysimmons on 24 Apr 2017

@brettsmason I agree with your assessment on 100% width and then having auto sizing be explicitly applied... the behavior in the current flex grid (and its difference from the float grid) is a constant source of confusion.

On the vertical front, that seems like a reasonable approach. Do gutters then apply vertically rather than horizontally as well?

kball on 24 Apr 2017

@corysimmons no problem and thanks for all your help with this :thumbsup:

@kball cool thanks for confirming, I'll go with 100% then.

Not sure on gutters. My initial thought was yes to apply vertical gutters, but not sure - I never used Apps so not sure on layouts that would typically be created. I know it has other uses though other than app style layouts.

Is there any way to get some of the Apps templates uploaded as working examples somewhere for me to check?

brettsmason on 24 Apr 2017

Your example showed horizontal grid nested within vertical

Flexbox should be either used horizontal or vertical... but not in combination

For Two dimensional grid system => CSS Grids is the correct approach and flexbox shouldnt be used!

IamManchanda on 24 Apr 2017

@brettsmason with regards to app grid, check out the work in this WIP PR: https://github.com/zurb/foundation-sites/pull/9487

@IamManchanda in 2018 CSS Grid is the correct approach... hopefully by late 2017 even... but the target with this grid is something that moves us forward and is actually usable for production projects today.

kball on 24 Apr 2017

@IamManchanda not everyone has the luxury of being able to use css grid, including me :smile:

brettsmason on 24 Apr 2017

I am not saying to use CSS grids right now
Check my above comment.... infact I am requesting to delay f7 to early 2018

I am just saying that....just meant that lets not look for a combination and keep it simple
Aka One way traffic!! @kball

IamManchanda on 24 Apr 2017

Same here @brettsmason... even I dont have :D

IamManchanda on 24 Apr 2017

@kball i was actually referring to these: http://foundation.zurb.com/apps/page-templates.html it would be nice to see them working so I have a better understanding of how everything fits together (the docs in the PR don't really give me an idea of the layouts it's for).

There's bound be a lot of overlap between the grids, just wondered how much and if they needed to be separate or not.

brettsmason on 24 Apr 2017

@brettsmason I think the grid is looking good! One thing that people have asked for and Flexbox can do well is a Block Grid - but with various width columns like: http://bulma.io/documentation/grid/columns/#multiline

I can add this in - where would be the best place to collaborate with you on the flex grid code?

rafibomb on 25 Apr 2017

👍1

@rafibomb I'm in the process of putting together mixins so I can put everything together correctly.
Once that's done I'll stick a branch online for you to take a look at.

I'm not sure I fully understand the difference with the multiline thing - isn't it just a row with flex-wrap: wrap on it?

brettsmason on 25 Apr 2017

@brettsmason Basically! I think a lot of it will be documenting the cool use cases which is where I can help as well.

rafibomb on 25 Apr 2017

@brettsmason => http://codepen.io/IamManchanda/pen/NjwKJO?editors=1100
@corysimmons => Can't this be a possibility .row>.columns>.columns>.columns>* and so on ??

PS: I am looking at this as a user of the grid!

Update: and here is the .row.reverse version of it
=> http://codepen.io/IamManchanda/pen/OmOJVo?editors=1100

IamManchanda on 6 May 2017

space-around/between will never work with margins. I fought with this for a month with every hack in the book.

.row could be thought of as .apply-a-negative-margin, and .column as .put-a-margin-on-each-side.

I really think Brett's simple flexbox mixin (I'd stick with horizontal-only to avoid confusion/pain) is the correct solution until grid spec is widely used.

Just make sure you expose a mixin to get gutter-aware sizes for fringe cases.

corysimmons on 6 May 2017

@corysimmons I added space-around for styling purpose ....
Here it is with flex-start => http://codepen.io/IamManchanda/pen/ybPORw?editors=1100

I am not a coding geek like you
but can't gutters be calculated (maybe calc) to make it work ??

PS: Again i am looking on it as a user!

.row could be thought of as .apply-a-negative-margin, and .column as .put-a-margin-on-each-side.

I know that and this is what i hate about it the most!

IamManchanda on 6 May 2017

.row {
  // ...
  width: initial;
  margin: 0 -15px;
}

.column {
  // ...
  width: calc(100% * 1/3 - 30px);
  margin: 0 15px;
}

Notice the inner columns aren't aligned flush with the original grid.

This is why you need to do: .row > .column every time you nest.

This extra markup is the price you must pay in exchange for not having to count columns per row.

corysimmons on 7 May 2017

Oh these gutters... Damn!

Ohk just for my personal knowledge
When I don't need gutters... Is this a good way to go about?

IamManchanda on 7 May 2017

Sure, but I think you'd better serve yourself, and your team, by agreeing to use 1 technique rather than mixing-and-matching—especially when the payoff is as minimal as a few less <div>s.

Terse markup seems thrown out the window with React, and React is curbstomping everything, so maybe terse markup doesn't matter after all.

Honestly, Brett has this already.

corysimmons on 7 May 2017

👍1

This is exactly why i cant wait for css grids to take over because it has gutters grid-gap inbuilt in them
https://codepen.io/enxaneta/pen/YZjJaW?editors=1100

IamManchanda on 7 May 2017

BTW update ..... CSS Grid now has 56.99% - 62.34% browser support!
(10x comparing back then when i opened this thread 50 days!)
Again,
Mobile browser is a big issue though!

IamManchanda on 7 May 2017

This is exactly why i cant wait for css grids to take over because it has gutters grid-gap inbuilt in them

Yeah, it took them a while to figure out this was a huge problem, but in the next few years markup will become really logical and terse.

Until it hits 90% global I won't use it.

Alright, I'm outta here again. Good luck team. Ping me if you have a direct question.

corysimmons on 7 May 2017

@corysimmons Sorry to bother you, I'm trying to get my head around a question with margin grids.
I've mainly used padding grids in the past, so struggling with the way to handle this.

A typical use case would be a solid coloured, full width background container, within this is our grid container, centred and contained to a max width. Then within that would be our columns etc.

Currently with a padding grid we would write:

<div class="header"><!-- background here -->
  <div class="row">
    <div class="logo">Logo</div>
    <div class="nav">Nav</div>
  </div>

However the above doesn't work with a margin based grid. We can't use margin: auto as we have a negative margin on the .row with a margin based grid.

What would be the best way of tackling this scenario in your opinion? Do we simply need to add an extra wrapper around the .row for this to work? Something like .row-container.

Also on smaller screens we have left/right padding currently that stops content from hitting the edges. Would adding padding to this .row-container work? Trouble with that is it wouldn't then line up to the rest of the grid elements.

Would appreciate your input as I'm keep to keep the new grid a margin grid!

brettsmason on 16 May 2017

I don't see a way to use max-width with margin-auto on margin-based grids without an extra container. Yuck. But if you only need one background color for the whole row, there's no reason to use a margin-based grid.

Again, I'd advise against letting the "gutter" interchangeably be margin OR padding. Define them both explicitly. Then, for this use case, you create a grid with x padding, 0 margin, and a max-width.

The caveat is, if you want a row like this…

…to have a max-width, you have to use an extra container. Which isn't so bad. Because with a padding-based grid, you'd have to use 4 extra containers (1 inside each of the columns).

andycochran on 16 May 2017

@andycochran After discussion with @kball I was planning on making the gutter margin only.
However I'm experimenting with real world situations/layouts and see how it would work.

So what you are suggesting is a way for a grid to have no gutter, margin and/or padding?
The complication is no gutters and padding don't need calc(), but margin does. Struggling to understand fully how that could work.

Would definitely like to discuss to get it nailed down though as the idea is interesting. I just don't want to end up with the mess of specificity like the current grid 😄

brettsmason on 16 May 2017

@andycochran Actually, I think: http://brettmason.co.uk/grid/ nearly does what you described. All I need to do is remove the .padding-gutters > [size]-[number] specificity and keep it on the margin option, as those widths are overwriting the margin based widths.

I'll put a demo together tonight and see what you think.

brettsmason on 16 May 2017

@andycochran Here's the demo I promised: http://brettmason.co.uk/grid/v2/
The 2 buttons toggles the classes on the grid. Is this what you meant?

brettsmason on 16 May 2017

👍2 ❤1

Can I get a CodePen for the background problem?

corysimmons on 16 May 2017

@corysimmons Sorry for the delay. Here's a quick CodePen: https://codepen.io/brettsmason/pen/ybRONQ
Basically with the margin grid we need an extra div in order to contain the width of elements within. I guess that's going to be the one main downside of margin grid compared to padding, but it also has a lot of positives.

brettsmason on 18 May 2017

If its just about adding a container ... Man i dont see it as a big issue !

IamManchanda on 18 May 2017

Yeah I think a wrapping element to an entire set of blocks is cheaper than what you'd have to do with current solutions.

https://codepen.io/corysimmons/pen/MmPyvd?editors=1100

Pretty much every padding grid does this thing where they assume no one wants actual margins between elements, and it's all faux. So when situations like this pop up, you can't just say "Just wrap the whole thing in a .bg element", but rather the user has to figure out a lot of markup bloat to make it work.

This is just one of the inherit problems with the negative-margin technique, and CSS layout in general. Hence I went with nth grids for like... ever.

corysimmons on 18 May 2017

@brettsmason @corysimmons not quite css guru like you guys
But what's the problem with margin: 0 -1rem; instead of margin: 0 auto;
https://codepen.io/IamManchanda/pen/bWmpax?editors=1100

IamManchanda on 18 May 2017

@IamManchanda the auto centres the element in the viewport. In your example everything is left aligned.

brettsmason on 18 May 2017

👍1

@brettsmason Not sure why he asked that, but just to be clear, .container _should_ be its own class, right?

corysimmons on 19 May 2017

@corysimmons Yes definately its own class. At the moment with the live grid its built into the .row class, which is a mistake.

brettsmason on 19 May 2017

👍1

It's better to correct mistakes
Instead of creating more mistakes due to an old created mistakes

IamManchanda on 19 May 2017

👍1

Foundation-sites: [Foundation Future] Discussion on Grid's Future ( Flex/Float/Spec - Margin/Padding )

Most helpful comment

All 101 comments

Related issues