Menu icon Foundation

Engineer | San Francisco, CA

James Stone is an award-winning web designer and a top contributor to ZURB Foundation. Learn how front-end code + living styleguide can reduce team conflict, personal stress, and improve workflow with his free Design Systems Crash Course below:

My Posts




My Comments

James Stone commented on Oliver's post over 1 year

Assuming you have a special.html file that is properly formatted in ~/src/layouts then you need to use the following format:
 
 
---
layout: special
---
 
So omit the .html form the layout name. Make sure your YML Frontmatter is at the top of your html file in ~/src/pages

James Stone commented on Christian Magill's post over 1 year

You have to think about the sequencing in which you are calling the mixins. For presentational classes, your scss / sass variables must be set prior to running the mixin.
You can say later on, set a variable:
$primary-color: #f00;
button { @include button; }
Just pay attention to the order in which you are going through the file. It reads top to bottom, starting at app.scss and then nesting in as many level deep, but still top to bottom.
In my opinion, you aren't going to gain much by doing this. I usually just make a copy of the _settings.scss file and any uncommented variables that I change for the project I do there. Then I import the foundation components one at a time. Often I end up with a scss file called something like _foundation-overrides.scss for things that I need to change globally, that can't be handed by the sass variables. This has to come after the foundation imports / includes. Then I have my own components, which might be built by scratch, or on top of a ZF component. I usually leave the variables (assuming they are component specific) in those specific files.
This way it is very easy for me to upgrade to new versions and determine which variable names have changed if any. I try and be reductive and only show the the variables that I am for sure changing, in the duplication of _settings.scss. I usually call it something like _some-project-variables.scss.
The only other thing that I might do is have a single file _some-project-brand-colors.scss that I will place first. Here I have named color variables (often generated out of something like zeplin.io) and then I set things like $primary-color to these.

James Stone commented on Luke's post over 1 year

Looks like you fixed it. What was the issue?
Perhaps you are using ZURB Foundation 5 and used bower update and got ZURB Foundation 6. That is just a wild guess though.

James Stone commented on Gregg Phelps's post over 1 year

It really depends on what you are trying to do. The easiest way is to add an import statement into your app.scss file.
@import "some-component";
This will import the file in your scss directory called "_some-component.scss"
As your project grows, you can place files into directories.
Ideally, you should end up with a single css file that is loaded in your web page. The above method provides that.
There are special use cases to developing specific files and compiling many of them, but that is not likely what you are looking for.

James Stone commented on Chuong Huynh's post over 1 year

@Steven Muncy

1) easiest method is to install via bower.

bower install --save foundation-sites

requires bower, and node

2) other method install via git

git clone git@github.com:zurb/foundation-sites.git

requires git.

Of course, neither of these are automatic, and you will need to pull boilerplate html and link to files correctly, or pull from this repo.

https://github.com/zurb/foundation-sites-template

3) Absolutely easiest install, zero deps. Use Yeti Launch. Mac Only.

If you are integrating into an existing app, using the cli is a lot of overhead and slow compared to using bower directly.

Often you will want to use something like bower to install and update and then create some sort of a build script using gulp or grunt. In Ruby and Middleman you can use sprockets (an asset pipeline) which does a lot of that automatically.

For other stacks you need to look into what is the best practices. There is no single solution that is easy and solves every use case for every type of integration.

James Stone commented on Chuong Huynh's post over 1 year

I think this is a very well thought out and reasonable response to working with ZURB Foundation for the first time coming from a Senior Front-end Dev position. I think he raises some valid points (many to which I think there is a rebuttal and stems from not understanding different ways in which to use Foundation) which could be greatly improved in the current Foundation docs and on boarding process.

For example, there are a lot of deps to install the foundation-cli. Does that mean it is the only way to install it, no. But the other methods are not as obvious or well documented.

Also, he takes the framework and its output from a basic level. There are several different ways you can implement ZURB Foundation such as only using components that do not use JS at all to his extreme of looking at every component and looking at the accessibility of each.

Since this article was written, ZURB Foundation 6 has been released which addresses a lot of the issues brought up.

I think although it is biased against using a framework to begin with, and also that it does have a biased viewpoint and tone, it provides some great insight to those working with Foundation and gives some great ideas of where things could be improved.

James Stone commented on Scott Koons's post over 1 year

I am using ZURB Foundation 6 with Flexbox Grid + Angular 1.4 on jamesstone.com.

James Stone commented on Bjarni Wark's post almost 2 years

This is exactly how a float based grid system works. Since you have two media queries, it is essentially 3 grids.

The padding on each column is the gutter. The row handles the max width (the width of the grid) as well as clearing the floats.

James Stone commented on Jim Preston's post almost 2 years

Looks like you are updated. It will only show the specific packages being updated and not the individual files. Bower basically automates the process of pulling down all of these git repos and their dependancies (such as jQuery).

It makes the whole process a lot easier to maintain because you can just update it all at once.

You also have the power to lock down specific versions on a project if you want in the bower.json file but that might be a bit more advanced. Usually you can just go with the latest version and everything should be ok.

James Stone commented on Jim Preston's post almost 2 years

Just spoke with the ZURB Team.

If you click on the terminal button (assuming you have installed node, npm and bower) you can just type "bower update" from that directory. This is your individual project directory, not the Yeti Launch projects directory.

This will update you to the latest version available.

They are planning to add a button that allows you to do this directly in Yeti Launch in the future.

Posts Followed








  • 4
    Replies
  • Update F6.0.0 to F6.1.2, How?

    By Jim Preston

    update process

    I used Yeti Launch to install F6.0.0 on 12/23/15 and all went well. I need the column uncentered class and it was supposed to be fixed in 6.1.1 so I tried npm update foundation-sites and bower update foundation-sites in terminal but they didn't seem to d... (continued)

    Last Reply by Rafi Benkual almost 2 years ago




Following

Followers

My Posts

My Comments

You commented on Oliver's post over 1 year

Assuming you have a special.html file that is properly formatted in ~/src/layouts then you need to use the following format:
 
 
---
layout: special
---
 
So omit the .html form the layout name. Make sure your YML Frontmatter is at the top of your html file in ~/src/pages

You commented on Christian Magill's post over 1 year

You have to think about the sequencing in which you are calling the mixins. For presentational classes, your scss / sass variables must be set prior to running the mixin.
You can say later on, set a variable:
$primary-color: #f00;
button { @include button; }
Just pay attention to the order in which you are going through the file. It reads top to bottom, starting at app.scss and then nesting in as many level deep, but still top to bottom.
In my opinion, you aren't going to gain much by doing this. I usually just make a copy of the _settings.scss file and any uncommented variables that I change for the project I do there. Then I import the foundation components one at a time. Often I end up with a scss file called something like _foundation-overrides.scss for things that I need to change globally, that can't be handed by the sass variables. This has to come after the foundation imports / includes. Then I have my own components, which might be built by scratch, or on top of a ZF component. I usually leave the variables (assuming they are component specific) in those specific files.
This way it is very easy for me to upgrade to new versions and determine which variable names have changed if any. I try and be reductive and only show the the variables that I am for sure changing, in the duplication of _settings.scss. I usually call it something like _some-project-variables.scss.
The only other thing that I might do is have a single file _some-project-brand-colors.scss that I will place first. Here I have named color variables (often generated out of something like zeplin.io) and then I set things like $primary-color to these.

You commented on Luke's post over 1 year

Looks like you fixed it. What was the issue?
Perhaps you are using ZURB Foundation 5 and used bower update and got ZURB Foundation 6. That is just a wild guess though.

You commented on Gregg Phelps's post over 1 year

It really depends on what you are trying to do. The easiest way is to add an import statement into your app.scss file.
@import "some-component";
This will import the file in your scss directory called "_some-component.scss"
As your project grows, you can place files into directories.
Ideally, you should end up with a single css file that is loaded in your web page. The above method provides that.
There are special use cases to developing specific files and compiling many of them, but that is not likely what you are looking for.

You commented on Chuong Huynh's post over 1 year

@Steven Muncy

1) easiest method is to install via bower.

bower install --save foundation-sites

requires bower, and node

2) other method install via git

git clone git@github.com:zurb/foundation-sites.git

requires git.

Of course, neither of these are automatic, and you will need to pull boilerplate html and link to files correctly, or pull from this repo.

https://github.com/zurb/foundation-sites-template

3) Absolutely easiest install, zero deps. Use Yeti Launch. Mac Only.

If you are integrating into an existing app, using the cli is a lot of overhead and slow compared to using bower directly.

Often you will want to use something like bower to install and update and then create some sort of a build script using gulp or grunt. In Ruby and Middleman you can use sprockets (an asset pipeline) which does a lot of that automatically.

For other stacks you need to look into what is the best practices. There is no single solution that is easy and solves every use case for every type of integration.

You commented on Chuong Huynh's post over 1 year

I think this is a very well thought out and reasonable response to working with ZURB Foundation for the first time coming from a Senior Front-end Dev position. I think he raises some valid points (many to which I think there is a rebuttal and stems from not understanding different ways in which to use Foundation) which could be greatly improved in the current Foundation docs and on boarding process.

For example, there are a lot of deps to install the foundation-cli. Does that mean it is the only way to install it, no. But the other methods are not as obvious or well documented.

Also, he takes the framework and its output from a basic level. There are several different ways you can implement ZURB Foundation such as only using components that do not use JS at all to his extreme of looking at every component and looking at the accessibility of each.

Since this article was written, ZURB Foundation 6 has been released which addresses a lot of the issues brought up.

I think although it is biased against using a framework to begin with, and also that it does have a biased viewpoint and tone, it provides some great insight to those working with Foundation and gives some great ideas of where things could be improved.

You commented on Scott Koons's post over 1 year

I am using ZURB Foundation 6 with Flexbox Grid + Angular 1.4 on jamesstone.com.

You commented on Bjarni Wark's post almost 2 years

This is exactly how a float based grid system works. Since you have two media queries, it is essentially 3 grids.

The padding on each column is the gutter. The row handles the max width (the width of the grid) as well as clearing the floats.

You commented on Jim Preston's post almost 2 years

Looks like you are updated. It will only show the specific packages being updated and not the individual files. Bower basically automates the process of pulling down all of these git repos and their dependancies (such as jQuery).

It makes the whole process a lot easier to maintain because you can just update it all at once.

You also have the power to lock down specific versions on a project if you want in the bower.json file but that might be a bit more advanced. Usually you can just go with the latest version and everything should be ok.

You commented on Jim Preston's post almost 2 years

Just spoke with the ZURB Team.

If you click on the terminal button (assuming you have installed node, npm and bower) you can just type "bower update" from that directory. This is your individual project directory, not the Yeti Launch projects directory.

This will update you to the latest version available.

They are planning to add a button that allows you to do this directly in Yeti Launch in the future.

Posts Followed

Following

Followers