Menu icon Foundation
Semantic grid classes @extend only grid

Hey peeps!

Want to start a discussion on grid classes and semantic classes in your markup.
Take a look at this PR https://github.com/zurb/foundation/pull/4134

Pros

Remove all the grid classes from your CSS
Reduces code bloat in your markup
Semantic CSS classes

Cons

Cannot rapid prototype
Existing members might find it difficult to adopt this system

But we can have a switch that turns this feature on or off, so people who want to use it this way can enable it. The rest of them have all the jolly goodness of what's already existing

Thoughts?

.tab-container{
@extend %large-6;
@extend %medium-8;
@extend %small-12;
(columns is not needed)
@extend %large-centered;
@extend %medium-centered;
}

<div class="tab-container">Blah</div>

as opposed to

<div class="large-6 medium-8 small-12 columns large-centered medium-uncentered">
    Blah
</div>     

gridfeature requestsemantic classes

Hey peeps!

Want to start a discussion on grid classes and semantic classes in your markup.
Take a look at this PR https://github.com/zurb/foundation/pull/4134

Pros

Remove all the grid classes from your CSS
Reduces code bloat in your markup
Semantic CSS classes

Cons

Cannot rapid prototype
Existing members might find it difficult to adopt this system

But we can have a switch that turns this feature on or off, so people who want to use it this way can enable it. The rest of them have all the jolly goodness of what's already existing

Thoughts?

.tab-container{
@extend %large-6;
@extend %medium-8;
@extend %small-12;
(columns is not needed)
@extend %large-centered;
@extend %medium-centered;
}

<div class="tab-container">Blah</div>

as opposed to

<div class="large-6 medium-8 small-12 columns large-centered medium-uncentered">
    Blah
</div>     
Kevin Lozandier over 5 years ago

It's not a good idea to use @extend in such a fashion.

You'll quickly have very unwieldy, unnecessarily long style declarations with your current use of @extend .

Personally, I have sort of a three-strikes-and-you're-out rule with @extend: If I find myself associating more than 3 CSS declarations to a single @extend, I refactor it to be a mixin to be kind to my future self.

Foundation Zurb already comes with a mixin that'll allow you to have the result you're looking for via the +grid-column() mixin

In fact, it's far less code using it than what you've provided above.

That's one of the key benefits of using the Sass version of Foundation you're currently not taking in consideration:

You don't have to restrict yourself to the "small", "medium", and "large" prebuilt breakpoints Foundation comes out of the box with for primarily the CSS version for the sake of a proper starting point for rapid prototyping with just classes.

Combined with media queries that come into fruition as you think about what sizes causes your vision of the site layout to break down (or using Sass extensions like breakpoint, a Sass extension dedicated to breakpoints and media queries, to help with this), the built-in mixins provided to you by the thoughtful folks at Zurb allows you to the freedom you want from the large-x, medium-x, and small-x classes already.

I've had to address this earlier this week actually through a SassMeister gist.

Going the next level towards the semantic grid system you're hoping to build for your project

After the rapid prototyping phase of your project, you may see that your page types are in very distinct blocks that warrants using a more simple or more robust grid behind the scenes: For example, you know you need at most 4 columns for a specific view port range or have a 2-8-2 ratio relationship between your sidebars and your main content.

In situations like that, you may want to use a dedicated grid framework like Singularitygs or Suzy.

Your mileage may vary; for example it may be optimizing too early or forcing relationships that just aren't there yet if you use such grid frameworks immediately in a project.

Being frameworks dedicated to grids, your rapid prototyping time is likely to increase and you may later find that it was overkill to take such a route (i.e., you find that just a 12-column grid will do you just fine) in the first place.

Vinay Raghu over 5 years ago

Hey Kev, thanks for the inputs and the stimulating conversation.
Here are my understanding of your responses and some additional questions

  1. Private grid systems

I know building your own grid is the best method and I have worked with frameworks such as susy and Singularity. i love singularity but assume I want to use foundation as a framework. I feel comfortable with the framework doing a lot of weight lifting for me and my project uses all their other components, so why not their grid?

Singularity is awesome...that's no reason why foundation's grid should be left behind.

I want to work with their grid system instead of a custom one, just that I want to extend my classes in my SCSS instead of having them in my markup

Its easy to customize their responsive breakpoints, what I don't like is so much of grid CSS when I might not be using all of them. Additionally, I don't want those classes in my HTML and would rather they stay in the CSS/SCSS.

  1. Using the mixin

Using their mixins does not work for me because I have to repeat the @media a lot of times. My requirement is as below

@extend %large-6;
@extend %medium-8;
@extend %small-12;
@extend %columns;
@extend %large-centered;
@extend %medium-centered;
@extend %hide-for-xlarge;

If I use the grid mixins to achieve this, I'd have to do something like the below several times

@include grid-column(12)
@media #{$small} {
    @include grid-column(8)
}
@media #{$medium} {
  @include grid-column(6)
}
....

I find this repetitive, especially the media tags and I don't like writing so many media queries. The foundation grid has already taken care of that for me. Instead of outputting ALL the classes, I want them to be silent placeholders, so I can grab what I want and use it in my code.

  1. Backward compatibility to IE8 and Affecting non power users

F5 does not support <IE9 but I understand IE8 is a big deal for a lot of people. Also, this is absolutely unnecessary for people who are already happy with what ships by default. So how about a switch that people who want to use this feature can turn on?

Kevin Lozandier over 5 years ago

The best option I could think of is deliberately not including the _grid.scss file and relying on the +grid-column mixin & Foundation's SCSS media-query variables instead.

If for some reason those items are also inside grid.scss, you'd have to extract them and the dependent variables involved. That shouldn't be a problem since Zurb's developers have done a good job putting all the variables inside _settings.sass for the most part.

Zurb likely can make these things separate from the rest of the grid.scss file, if they're in there, from the rest of that file generating the CSS related to the grid you don't want.

If enough people request it, I'm sure it'll be done soon (if not in the works already).

I mentioned this feature/improvement before and other meta-programming features involving Sass 3.3 last summer actually; now that Sass 3.3 is officially released and Foundation 5 being in a mature state, I hope this in particular is being considered.

Scott Kellum over 5 years ago

Foundation has a lot of users in the growing libsass community so while 3.3 features are awesome and we use them extensively in the latest release of Singularity to do really crazy and awesome stuff with grids, Foundation would be turning its back on a lot of people if it required extends for its grids.

That said, I would love to see the Foundation grid be a lot more powerful and flexible than it is right now. Mixins are supported in a wide variety of Sass environments. Focusing on mixins first is a step in the right direction towards flexibility. You can easily set up multiple grids for multiple breakpoints if you want. Nesting can be calculated on the fly. Making the assumption that a grid works in a specific way constrains design in a way that is un-necessary.

Note I am the creator of Singularity, so I have a bias towards it. It is a different mental model from most grid systems. Foundation works for a lot of people, more power to y’all.

Noor over 5 years ago

There's been a lot of discussion about semantic grid classes in the Bootstrap community lately.

The main drawback with using @extend is that you end up with very large stylesheets.

This raises another issue with the use of front end frameworks and that is, in general, only a small percentage of a framework is ever used in a project.

It is my opinion that part of a modern development workflow, when making use of great front end frameworks such as Zurb, should be the removal of excess CSS during preprocessing. Grunt plugins like Uncss (grunt-uncss) make this process quite easy and would have the effect of not only reducing stylesheet bloat in projects utilising @extend for semantic grid classes but dramatically reduce the amount of unused framework CSS overall.

I see this as a win-win.

Vinay Raghu over 5 years ago

I agree with Scott. @mixins are probably a better way to go about this since @extends are easy to abuse and end up bloating your stylesheet. At the same time, Foundation needs a better grid system than what is currently present.

While what we have is good for prototyping, foundation prides itself as a framework that offers more customizations and less assumptions about how you use it. Having a flexible grid system is a step forward in that direction.

I am going to go out and build a bunch of mixins to see if we can include that. I would like to know what the core team thinks though.

Frank B over 5 years ago

I like the idea, but for my situation it would be really bad if the classes get removed.

I work for a company that creates websites with the TYPO3-CMS + Foundation. In the next months we're going to build a couple of websites for 'big' customers, like a Dutch technical university and the second biggest Dutch labor union.

Our customers have a lot of freedom in the backend. We define a couple of templates with fixed area's where users can put content in. This content can be all different kinds of stuff, like forms, sliders, customer-specific elements etc. But it's also possible to create a container inside the area, and split the area into multiple new columns. In those columns they can put content elements, or split it up again... Etcetera...

Note: some of our customers have over 500 backend users. Those users have (and need!) a lot of freedom in the backend. They also really use this freedom, since they sometimes want/put contentelements on unexpected places. For that reason, we have a strict seperation of grid and content. A tab-container (which is content) that defines it's own size would offend all our styling rules. As fronteer I don't even have access to the grid classes in the HTML, since they're generated by TYPO3.

Because of the freedom for our customers, I never know how many columns a specific content element should take, because all content elements can be placed on multiple and different places in the website (or in one of the many subwebsites).

I like the idea of reducing Foundations css-output, but please also keep the current system of defining the grid with classes. (maybe with something like $include-html-grid-classes ?)

tl;dr: we keep the grid seperated from our content and we can't change this behaviour. Please keep the classes :)

Vinay Raghu over 5 years ago

@Frank agreed. The initial proposal was to keep the existing as default. and whoever wants to use @extend only turns that variable on and no grid classes are output to the CSS. only extends

But actually, there doesn't seem to be any favor to that approach - especially the sass community. They think foundation's and any 12 column grid is superfluous and imposes constraints to your design.

The alternative is to either adopt a requirement specific Sass based grid framework such as Susy or Singularity that provides more flexibility.

The other option is to make foundation's grid scale up to such higher expectations, which might take it forward but not be useful for people who use it only for prototyping. Am assessing if this effort is worth taking and whether Zurb users would really benefit from it.

Am currently trying to wrap my head around singularity and work some things out. So will keep you posted on the progress. Thanks for your inputs!

Carlos Morales over 5 years ago

Hi, I am the creator of the pull request for this feature.

"The main drawback with using @extend is that you end up with very large stylesheets."

Not if you use them properly. The idea is to extend placeholders, not any other selector. If you @extend a selector, you add ALL its styles to the CSS, so it gets bloated indeed. If you extend a placeholder, only that code is added. You actually end up with a bigger CSS using mixins, since those mean reppeated code.

Please take a look at this link http://ianstormtaylor.com/oocss-plus-sass-is-the-best-way-to-css/

Extending placeholders, is it possible to use a convenient grid like Foundation one, and use semantic selectors at the same time. Sure, if lots of selectors @extend the same placeholder, you end up with a huge list of selectors in your CSS, maybe difficult to spot... but you save thousands of lines of code while being semantic.

For me, the benefits surpass the drawbacks.

Glenn Philp over 5 years ago

Isn't it best to turn off $include-html-class: false, then using your semantic structure like follows:

.header {
  @include grid-row();
}

.branding {
  @include grid-column(6); //If using a 12 column grid this would be 50%
}

By turning off the HTML classes you are able to still harness the power of foundation, yet make the output stylesheet(s) smaller and semantic. The main purpose of Foundation out of the box is for quick prototyping. It is highly recommended after prototyping to revisit the site create and make it smarter and lighter.

Carlos Morales over 5 years ago

@Glenn Philp

Your solution works until you want to use
SCSS
@include grid-column(6);

(or any other mixin) in several places. All the code generated by that mixin will get repeated every time you include it, something that won't happen if you extend a placeholder.

Sure, you could try to find all the places where you repeat that mixin, combine the selectors and move them somewhere else, like this:

.branding,
.box,
.other-selector {
  @include grid-column(6); 
}

...but that will mean manually doing what extending a placeholder is essentially doing for you.

In addition, I like to organize my stylesheets in sections (general layout, specific pages layout, buttons, etc) and it would be really difficult to keep that organization if grouping selectors.

"It is highly recommended after prototyping to revisit the site create and make it smarter and lighter."
If I don't use presentational classes from the start, and use placeholders, I get a smarter and lighter output without the need to revisit the code a second time.

Dmitri Pisarev over 5 years ago

I totally agree with Carlos and that's exactly how I use @extends. @extends produce less coe than @mixins when used properly.

Actually for grid I would still be using classes in HTML, as it makes it just more readable for me, but for stuff like visiblity classes, block-grids and so on I would prefer to extend silent %placeholder classes.

lmseo almost 5 years ago

This is actually a great idea that I was thinking for quiet some time. My biggest problem with using front-end frameworks is that I have to sacrifice performance over fast prototyping. Compiled files are several times bigger due to the fact that CSS files usually include a large number of styles that never get used throughout the project.

The use of SASS @entend and placeholders is a way I use in my own projects to accomplished two separate goals. First, decrease file size by only including styles that I'm actually using in the project. Placeholders don't get compiled unless they are extended. Take for example:

.large-8{width:66.66667%}

This style will show in your final CSS file even if you never use it anywhere in your project. However, if written using SASS placeholders

%large-8{width:66.66667%}

The style never gets included unless it is extended somewhere in the project. Or take for example when working WordPress structural wraps classes are called .wrap as opposed to .row in Foundation.
Normally, I would use this:

.wrap{
@extend{row}
}
which compiles to:
.wrap, .row{....}

However, if using placeholders .row never gets compiled and .wrap is the only class showing in the final CSS, way cooler.

Finally, being able to use semantic CSS in my projects as opposed to a chain of classes to accomplish the same result which I believe @VINAY RAGHU was originally aiming for with this post.

I include a post on OOCSS and SASSS that I believe explains this point in more detail.
http://ianstormtaylor.com/oocss-plus-sass-is-the-best-way-to-css/