Menu icon Foundation

Developer | Boulder, Co

My Posts

No Content

My Comments

Justin J commented on Justin J's post almost 4 years

No, it's not to do with the syntax. Here, this works:

 # These first lines are right from the docs:  
foundation new project_name --libsass
cd project_name
grunt build
# add the mixin: 
echo '.custom-button-class {  @include button();  }' >> ./scss/app.scss
#compile: 
grunt

Putting the mixin in app.scss at least doesn't produce an error as it does for _settings.scss - I haven't checked if it produces the .css I wanted yet.

The flow of the docs on this page:

http://foundation.zurb.com/docs/using-sass.html

Introduce _settings.scss, then mixins, then the app.scss. To me, that's a little out of order and not clear or apparrent.

Would you introduce your mouth, food, and your butt, and then have people go, "well, I guess I stick food in my butt!".

Just say, "Hey, mixins go in this file (then introduce the file)" and bang! your docs are better.

Justin J commented on Justin J's post almost 4 years

Here's the simpliest way I can recreate the problem:

# These first lines are right from the docs:  
foundation new project_name --libsass
cd project_name
grunt build
# add the mixin: 
echo '.custom-button-class {  @include button($padding, $bg, $radius, $full-width, $disabled, $is-input);  }' >> ./scss/_settings.scss
#compile: 
grunt

Output:

Running "sass:dist" (sass) task
>> no mixin named button
>> 
>> Backtrace:
>>   scss/_settings.scss:1490
>>   Line 1490  Column 34  scss/_settings.scss
Warning:  Use --force to continue.

Aborted due to warnings.

So... what am I doing incorrectly?

Justin J commented on Justin J's post almost 4 years

In the, scss/_settings.scss file - see my initial post for the output I'm seeing in grunt.

According to the docs (http://foundation.zurb.com/docs/using-sass.html) that does seem to be the place to do such work, if I'm reading this right. I tried the example that's on that page by adding it to the _settings.scss file and saving. That's when grunt comes back with the error.

Justin J commented on Justin J's post almost 4 years

Yup, everything is getting imported - I started the project exactly as the docs, uh, document:

cd path/to/sites
foundation new project_name --libsass
cd project_name
grunt build

There seems to be a step I may be missing to use this sort of mixin, I'm guessing.

Justin J commented on Justin J's post almost 4 years

Maybe I should describe how this was solved, before moving to Foundation:

We just had the main content in a div, with a specific id. The stylesheet that we used only applied styles using that ID (for example the id would be, "appname" - so instead of,

input[type="text"] { 
     // yadda yadda
}

We would just specify it as,

#appname input[type="text"] { 
     // yadda yadda
}

That allows the design we're basically using as shell around the main content to have styles that are independent of the main content (that we're producing) - there's just two stylesheets. Wanna overload any style? Just use another stylesheet.

Wonder if something like that could be used with Foundation? (specific div that all Foundation styles would use).

Justin J commented on Justin J's post almost 4 years

OK, Chris thanks. I'm looking forward to Foundation 6, which should be ready once I'm done converting this enormous project over to Foundation 5! (just my luck, eh?) Hopefully, the migration from 5->6 will be nice and smooth.

I may just look into a way to communicate that things are happening, before the ajax call is complete, in a slightly different way (or go back to Colorbox - hoping to get away from it to Keep Things Simple). I can already see how freezing the entire app is going to cause my users headaches.

Justin J commented on Justin J's post almost 4 years

I was hoping for something even simpler than that. For example, if there was a data attribute, you could just set on a preceding reveal:

 $('#myModal').foundation('reveal', 'open', {
   data: 'string showing my loading widget'
});
// And then, 
$('#myModal').foundation('reveal', 'open', {
    url: 'http://some-url-with-the-slow-loading-return-value',
    data: {param1: 'value1', param2: 'value2'}
});

Or setup as a callback, or whatever.

The whole, "freezing" of the entire interface" is a way less than ideal. Other than revealing hidden divs with data already present, the reveal modal is pretty restricted.

Posts Followed

No Content

Following

    No Content

Followers

My Posts

No Content

My Comments

You commented on Justin J's post almost 4 years

No, it's not to do with the syntax. Here, this works:

 # These first lines are right from the docs:  
foundation new project_name --libsass
cd project_name
grunt build
# add the mixin: 
echo '.custom-button-class {  @include button();  }' >> ./scss/app.scss
#compile: 
grunt

Putting the mixin in app.scss at least doesn't produce an error as it does for _settings.scss - I haven't checked if it produces the .css I wanted yet.

The flow of the docs on this page:

http://foundation.zurb.com/docs/using-sass.html

Introduce _settings.scss, then mixins, then the app.scss. To me, that's a little out of order and not clear or apparrent.

Would you introduce your mouth, food, and your butt, and then have people go, "well, I guess I stick food in my butt!".

Just say, "Hey, mixins go in this file (then introduce the file)" and bang! your docs are better.

You commented on Justin J's post almost 4 years

Here's the simpliest way I can recreate the problem:

# These first lines are right from the docs:  
foundation new project_name --libsass
cd project_name
grunt build
# add the mixin: 
echo '.custom-button-class {  @include button($padding, $bg, $radius, $full-width, $disabled, $is-input);  }' >> ./scss/_settings.scss
#compile: 
grunt

Output:

Running "sass:dist" (sass) task
>> no mixin named button
>> 
>> Backtrace:
>>   scss/_settings.scss:1490
>>   Line 1490  Column 34  scss/_settings.scss
Warning:  Use --force to continue.

Aborted due to warnings.

So... what am I doing incorrectly?

You commented on Justin J's post almost 4 years

In the, scss/_settings.scss file - see my initial post for the output I'm seeing in grunt.

According to the docs (http://foundation.zurb.com/docs/using-sass.html) that does seem to be the place to do such work, if I'm reading this right. I tried the example that's on that page by adding it to the _settings.scss file and saving. That's when grunt comes back with the error.

You commented on Justin J's post almost 4 years

Yup, everything is getting imported - I started the project exactly as the docs, uh, document:

cd path/to/sites
foundation new project_name --libsass
cd project_name
grunt build

There seems to be a step I may be missing to use this sort of mixin, I'm guessing.

You commented on Justin J's post almost 4 years

Maybe I should describe how this was solved, before moving to Foundation:

We just had the main content in a div, with a specific id. The stylesheet that we used only applied styles using that ID (for example the id would be, "appname" - so instead of,

input[type="text"] { 
     // yadda yadda
}

We would just specify it as,

#appname input[type="text"] { 
     // yadda yadda
}

That allows the design we're basically using as shell around the main content to have styles that are independent of the main content (that we're producing) - there's just two stylesheets. Wanna overload any style? Just use another stylesheet.

Wonder if something like that could be used with Foundation? (specific div that all Foundation styles would use).

You commented on Justin J's post almost 4 years

OK, Chris thanks. I'm looking forward to Foundation 6, which should be ready once I'm done converting this enormous project over to Foundation 5! (just my luck, eh?) Hopefully, the migration from 5->6 will be nice and smooth.

I may just look into a way to communicate that things are happening, before the ajax call is complete, in a slightly different way (or go back to Colorbox - hoping to get away from it to Keep Things Simple). I can already see how freezing the entire app is going to cause my users headaches.

You commented on Justin J's post almost 4 years

I was hoping for something even simpler than that. For example, if there was a data attribute, you could just set on a preceding reveal:

 $('#myModal').foundation('reveal', 'open', {
   data: 'string showing my loading widget'
});
// And then, 
$('#myModal').foundation('reveal', 'open', {
    url: 'http://some-url-with-the-slow-loading-return-value',
    data: {param1: 'value1', param2: 'value2'}
});

Or setup as a callback, or whatever.

The whole, "freezing" of the entire interface" is a way less than ideal. Other than revealing hidden divs with data already present, the reveal modal is pretty restricted.

Posts Followed

No Content

Following

  • No Content

Followers

  • No Content