Talking about => http://foundation.zurb.com/sites/docs/flexbox.html#vanilla-flexbox-helper-classes
Inspiration => http://v4-alpha.getbootstrap.com/utilities/flexbox/
Pro: Can help a lot with responsiveness.
Cons: Bulky generated CSS file.
Me and @kball are looking for discussion on this
=> @ncoden @DaSchTour @andycochran @natewiebe13 @tdhartwick and all other interested zurbian's. I am talking about you!
Pro: Can help a lot with responsiveness.
Yes it can help a lot with responsiveness, can't argue with that.
Cons: Bulky generated CSS file.
But the bootstrap link you provided looks bulky with too much css classes!
One thing our company is trying to do is getting away from using helper classes as much as possible, and instead using semantic classes wherever possible. Helper classes make more sense for high level layout, but components themselves should have these sorts of things defined within CSS.
I almost wonder if it would be better to include mixins for these instead of classes. We've noticed that when using a framework, people start to use it as much as possible to do styling, then only add extra styles if they need them, when really is should be the other way around.
I would argue that helper classes can be overused and starts to become similar to using inline styles, so we need to be careful how many utility classes get included.
It may be a good idea to take a step back, and determine what kind of utility classes would be useful for higher level layout, instead of adding every possible combination of helper classes.
I totally agree with you @natewiebe13 !!!
I almost wonder if it would be better to include mixins for these instead of classes.
Yup even i wonder the same like you @natewiebe13 . Will be great if we can add mixins instead of classes.
I think focusing on the mixins is a good idea; I think we have more opportunity for having mixins like this, and we can even include an equivalent to the foundation-* mixins that create all of the helper classes, but not include it by default, so folks who really want these can get it easily.
I think focusing on the mixins is a good idea; I think we have more opportunity for having mixins like this, and we can even include an equivalent to the
foundation-*mixins that create all of the helper classes, but not include it by default, so folks who really want these can get it easily
Ohk so its finalized ..... we will have mixins.
Who wanna do a PR ?
I will be happy to do too.
Important: @kball @brettsmason , I Started working on this but here is what i have found in the generated css ( flexbox mode ) before doing anything
=> https://gist.github.com/IamManchanda/983ea09c360e2252e70a64eaa42a661a
Source => https://github.com/zurb/foundation-sites/blob/develop/scss/grid/_flex-grid.scss#L249-L265
Forget Mixins, these classes are already there .... for eg.
.flex-dir-row {
flex-direction: row;
}
@media print, screen and (min-width: 40em) {
.medium-flex-dir-row {
flex-direction: row;
}
}
@media print, screen and (min-width: 64em) {
.large-flex-dir-row {
flex-direction: row;
}
}
Just that's it is not documented in the docs FWIW.
BTW .flex-container, horizontal and vertical alignment classes are missing from these responsive variations though at the moment.
But all the other vanilla flexbox helper classes are available as responsive variations as attached in the gist above.
Now What ???
lol can't stop my laughter :stuck_out_tongue:
@IamManchanda if the requested classes are already there, perhaps a PR updating the docs?
Ohk @kball but i will first add .flex-container into them as it deserves to be there (obviously).
And what about horizontal and vertical alignment classes ??
Should i make responsive variation for them or not ?
@IamManchanda what do you think the status of this one is?
Most helpful comment
One thing our company is trying to do is getting away from using helper classes as much as possible, and instead using semantic classes wherever possible. Helper classes make more sense for high level layout, but components themselves should have these sorts of things defined within CSS.
I almost wonder if it would be better to include mixins for these instead of classes. We've noticed that when using a framework, people start to use it as much as possible to do styling, then only add extra styles if they need them, when really is should be the other way around.
I would argue that helper classes can be overused and starts to become similar to using inline styles, so we need to be careful how many utility classes get included.
It may be a good idea to take a step back, and determine what kind of utility classes would be useful for higher level layout, instead of adding every possible combination of helper classes.