Feedback: Sass exports

[gakimball]

For Foundation 6, we're changing how CSS is exported to hopefully be simpler to understand.

Simply importing the framework doesn't output CSS. This makes it easy to @import the entire framework and not worry about which pieces you want right away.

Compile times may be a concern, but the increasing robustness of libsass makes the compile times negligible.

CSS exports are handled through mixins. So a stock app.scss might look like this:

@import 'settings';
@import 'foundation';

@include foundation-global-styles;
@include foundation-grid;
@include foundation-button;
// And so on...

This also allows components to be namespaced.

#foundation {
  @include foundation-grid;
}

[OndrejVasicek]

So, what’s the benefit for the developer then?

@import 'foundation/components/buttons';

and

@include foundation-button;

seems to be equal in this case.

Can you please mention some real example of namespaced component? I’m trying not to use mixin unless I need parameters. Until then I use @extend to avoid duplicating code. But maybe it’s just my ignorance of some pattern.

[gakimball]

@OndrejVasicek This pattern creates a more clear distinction between importing the code of a component (the variables, mixins, and functions that make it work), and exporting the CSS of a component. The @import simply pulls in the library, while the @include exports the CSS.

The benefit is that importing a component for its mixins only is much easier. In Foundation 5, you need to un-import components you don't want at all. But if you want a component just for its mixins, you need to keep the import, but then dig into the settings file and find the variable to disable that specific component (e.g., $enable-html-grid-classes).

For developers who don't care about all the semantic hooks, nothing really changes, because like you said, an @include is more or less equivalent to an @import. But for developers who use component mixins, the setup is much faster.

Here's an example of namespacing (this isn't possible with @import statements):

#foundation {
  @include foundation-everything;
}

[OndrejVasicek]

@gakimball aaah... I think I see the light now. So the main benefit is, you don't get the css messy, if you only need to use some of the mixins from the component (or you don't have to turn them off).
In fact, you don't even have to use the foundation-* "export mixin" and you can create your own classes via the *-base, *-style etc mixins. Again, without messing with the default foundation classes. Am I correct? In my case, it's a rare situations, but it’s really convenient some times.
About namespacing – I was searching for a situation, where you can’t use extend and must use include, even if your mixin doesn’t have parameters.
But I was wrongly thinking, that I could have replace

#foundation {
  @include foundation-button;
}
#foundation-brother {
  @include foundation-button;
}

by this one

@include foundation-button;
#foundtaion{
@extend .button;
}
#foundtaion-brother{
@extend .button;
}

Which I of course could, and would get less css in result (profit), but then I realized, that

@include foundation-button;

exports more than that one “.button” class.
You may also want use namespacing in situations, where you have only one namespace, which is no benefit for extends.

So the result – my mistake – even the namespacing is useful here, thanks to the new clearer way you guys handle with components and mixinx.

For me – thumbs up for sass exports.

[colin-marshall]

I definitely think this new setup is a better way of dealing with Sass in Foundation. Nice work.

[erutan]

I'd generally only include the components I'd need, and turn off CSS rendering for everything that didn't deal with the element level (typo, forms, etc), so this definitely makes life easier!

If you wanted to make it a bit more explicit it'd be nice if the includes had a prefix like export or render, e.g.

@include export-foundation-global-styles;
@include export-foundation-grid;
@include fexport-oundation-button;

[zurbrandon]

Thanks for all the feedback, everyone! The team has went over all these discussion topics and have either incorporated the feedback, have a plan to incorporate I or decided to not include it.

We'll close these topics, but feel free to keep adding and discussing if you'd like.