foundation / foundation-sites

The most advanced responsive front-end framework in the world. Quickly create prototypes and production code for sites that work on any kind of device.
https://get.foundation
MIT License
29.67k stars 5.48k forks source link

all variables are initally uncommented in _settings.scss? #7328

Closed yucelm closed 8 years ago

yucelm commented 8 years ago

The foundation doc says in order to make a change, variables must first be uncommented (http://foundation.zurb.com/apps/docs/#!/sass - "The Settings File" section Paragraph 3) Yet when I create a project, all of the variables inside the _settings.scss file are already uncommented?

If I were to comment any of them, that component becomes unusable. No default styling is available. Any ideas why?

abdullahsalem commented 8 years ago

Hi @yucelm, I've commented the whole variables in scss/settings/settings.scss to be matched what is written in the documentation. However, you should not face any problem either it's commented or uncommented, because the default variables should work instead!

yucelm commented 8 years ago

Thanks. I am just checking it out. I just wanna ask you another quick question if you don't mind.

In the app.scss file, the main foundation file is already imported at the top "@import 'foundation';" When I comment out one of the includes however (i.e @include foundation-grid;) it breaks that component.

Aren't all components already included in the main foundation file anyways? Should it not work regardless even though I comment out the individual components?

Thanks a lot.

abdullahsalem commented 8 years ago

I understood that you are trying to code>@import</code the Foundation's component, but NOT code>@include</code its mixin, if you did so, that component will NOT work, because you only code>@import</code its FILE but didn't call its mixin, and this is a major difference between F5 and F6. In F5, you only need to code>@import</code the component's file but in F6 you need to code>@include</code its mixin too.

yucelm commented 8 years ago

I see that is something I wasn't aware of. It is clear now.

May I ask what was the purpose of doing it this way? I mean including the mixins in addition to foundation import?

abdullahsalem commented 8 years ago

I hope everything goes well.. Good luck,

KnightYoshi commented 8 years ago

@yucelm So that when using a component the classes are not automatically added into the CSS, you can use the mixins easily for your own classes, and to remove the need for a variable to check if it should include the CSS at a global level and on a per component level (I think to clean up fragmentation).

If you want to include all the Foundation classes use @include foundation-everything();

yucelm commented 8 years ago

@Knight-Yoshi It is super clear now. I haven't had enough time fully review all the changes in F6. Many thanks.

gakimball commented 8 years ago

We made a last-minute call to uncomment every variable in the settings file, but the documentation wasn't updated to match. I updated it yesterday: 2d0daf9703a660679ef0c291a6380d8077add67b

The reason we're uncommenting every variable is to avoid reference errors. For example, let's say you left all the colors the same, so they all have comment marks. Now you try to reference $primary-color farther down, and you get an error, because $primary-color hasn't been defined yet. It is in the settings file, but it's not uncommented. Uncommenting every value gets around this issue.

abdullahsalem commented 8 years ago

Hi @gakimball, I've just noticed the major difference between my own Build Flow and the other one you assumed, and before I go further in explaining that difference, I am going to share you few things of my projects that are based on Foundation.

I usually use Foundation as a base of my projects, then add my code and other third-parties. Therefore, that collection leads me to make my own custom build steps.

When I came to Foundation -F6 in particular-, I saw that its sass build walks through the following steps: @import 'settings'; @import 'foundation'; @include foundation-everything;

Thus, that flow might cause a "reference errors" when one of the commented variable is called within the settings.scss.

It's great idea that the settings.scss works as a secondary configuration layer -current situation-, but when we use it in the previous order -before @import 'foundation'; - that will lead us to some challenges, "reference errors" one of them. In my opinion, that secondary configuration layer settings.scss should come after calling the initial components' settings @import 'foundation';, so all the variables that are written in the settings.scss should be already initialized in @import 'foundation'; step, thus, will not be any dependency inside the settings.scss itself.

The following picture abstracts the build steps that I do: f6-build-flow

@import 'foundation'; @import 'settings'; @include foundation-everything;

Finally, I would really appreciate it if anyone has any concern or improvement regarding to the suggested build steps.

Enjoy F6 :)

KnightYoshi commented 8 years ago

@abdullahsalem The @import 'foundation'; loads all of Foundation's mixins. The _settings.scss file uses some of the mixins, such as rem-calc(). This would also be necessary if you used any of the Foundation mixins yourself in the _settings.scss file.

I don't see any point in loading the settings file before the main foundation file.

abdullahsalem commented 8 years ago

I've just noticed that some setting variables depend on each other, for instance

/// Default pip width for tooltips.
/// @type Number
$tooltip-pip-width: 0.75rem !default;

/// Default pip height for tooltips. This is helpful for calculating the distance of the tooltip from the tooltip word.
/// @type Number
$tooltip-pip-height: $tooltip-pip-width * 0.866 !default;

And if you would like to change the $tooltip-pip-width value in the settings.scss, according to my suggested order:

@import 'foundation';
@import 'settings'; 
@include foundation-everything;

You will need to re-configure all variables that use $tooltip-pip-width to take the new value, such as $tooltip-pip-height in the previous example.

Thanks for sharing guys..

gakimball commented 8 years ago

The reason we imported the settings file before the framework in Foundation 5 was because the act of @importing something would print the CSS. So by the time you've called @import 'settings', the framework has already done its thing and printed the CSS with the default settings.

The new model in Foundation 6 was supposed to fix this, but we still ran into some issues and ended up keeping it how it was.

abdullahsalem commented 8 years ago

Thanks @gakimball , I do appreciate all what you have been doing on F6, it's great work.. :+1: