We're using the SASS version of Foundation 4.
A co-worker is saying you shouldn't modify the sass files in case you want to update it in the future; which is a good point.
I think it's necessary to modify the files in order to make proper use of the existing mixins and nesting.
I'm hoping someone with more experience could shed some light on the proper way to use the framework.
For development I would definitely suggest not touching the core files as your co-worker pointed out.
Since you are using SCSS, you can easily include the core files into your own version of them (which add/overwrite rules).
Example: /scss/custom/components/_my_alert-boxes.scss
#import("/scss/foundation/components/_alertboxes.scss") // Foundation core
$alert-border-style: dashed;
#mixin alert-close {
//Override default mixin.
}
Then once you are ready for production you'd want to go back and remove all the unused rules, minify code, and all that good stuff.
Related
I am beginning to use Go for web development, but I am having issues with asset management. I would prefer to have a tool like Rails' Asset Pipeline for managing (and compressing) css/js files (as well as SASS), but I am still able to work with css and js files.
While I am able to work with css and js, I am not able to work with SASS. Is there a way to use SASS in a Golang project? I am not using a framework.
Thank you!
I'm not familiar with Ruby on Rails but, I assume, that ruby on rails gave you some sort of tools for managing the source to distribution client-side asset transition (polyfills, transpiling, minification, compiling of SASS/SCSS to CSS, compiling of XScript to JavaScript ... etc).
While a web development framework might do that to try and ease in developers quickly (I assume rails does that, not ruby) its not exactly the way Go does stuff.
Go is a language, not a framework + language, just a compiler, a few build tools and a set of standards for how to write, test, document and indent stuff (with the indent,test and document part being optional).
A go server, at least the way I built servers with go, is somewhat decoupled from the client. It server static assets when they are needed (e.g. it serves the minified JavaScript and the stylsheets and the html, and jsons with info from the databases... etc), but it doesn't really care about what those are, its a server. The go toolchain is made for building golang applications (e.g. said server), but its not made for building client-side web applications (those consisting of js, css and html).
Now, you may use a framework similar to rails written in go that helps "pack up" css, js, html. But I'm unaware if there are any.
You may use a compiler which turns go into client-side code (i.e. javascript) https://github.com/gopherjs/gopherjs , if you enjoy the go toolchian and want to use it for client-side development. But, go-like performance isn't something this gives you AND you are working with a subset of go. Its really just a different way to write javascript.
However, what you most likely need in your case is a "build-chain" for your client side. Here there are 3 tools which (in my opinion) stand out in 2016:
npm
webpack
bower
I could write an essay about using this tools but here's the summary:
Webpack is used to create a "pipeline" for your code which does thing like, calling babel on javascript, compiling sass to css, minifying assets, allowing js to be written with import syntax... etc, really, its a swis army knife in your js development arsenal and probably matches the functionality of whatever you were using before.
Npm is the node package manager BUT even if you are not using node for your server. It can be useful to keep tracks of dependencies for building your application (like webpack) and for downloading modules. Its also useful for running various scripts and deployment, its a bit of an overkill to use both npm and weback though you will probably have an easier time setting up the webpack enviornment if you have a package.json (config file for npm) with each of your project.
Bower is one I actually don't use for small projects. But its basically a repository for javascript libraries (among other things), so you can easily say, write "bower install jquery" and you've downloaded jQuery for your current project.
Again, there are many other tools out there, these are just some of the ones I like, but, check some of them out. They can help you replaces your previous pipeline. Don't think of client and server side code as being the same, they are decoupled and having a strong separation between them might help you a lot.
The problem I am encountering a great number of imported files. I am trying to slowly inject webpack into a legacy site. There are many global stylesheets:
require('../../../Content/Ones/_forms.scss');
require('../../../Content/Ones/_grid.scss');
require('../../../Content/Ones/_panels.scss');
require('../../../Content/Ones/one.scss');
require('../../../Content/Ones/_grid_tools.scss');
Is there a way to avoid this? I might be just looking at this from the wrong angle because I can't seem to find a question that matches my use case.
Please advise, Thanks!
The SASS files you import (whether you import them from a JS file or another SASS file) are part of your webpack dependency tree, so they should all be watched automatically. If they're not, would you mind adding some more info to your question about your app structure and webpack config?
As for reducing the number of global SASS imports, there are a few ways to do that, but making a good choice here really depends on how your app is structured.
Side question: Is there a reason you're adding webpack to this site? Anything in particular you're hoping to gain? I ask because if it's not a component-based SPA, you might not be getting very much out of webpack, and it may not be worth the trouble.
I use Zurb Foundation along with Susy grids, they both have a mixin named "prefix". I'm using "bower" to include them in my project, so how to namespace them without changing in their source code?
I can imagine only a not so clean way:
if you can separate the .scss that is using Susy grids from the other foundation stuff, you could use grunt to compile 2 separate files, one sass run for foundation and one run for Susy grids, then eventually merge the 2 outputs.
Sass does not offer namespacing at this point in time. It is a planned feature for 4.0.
I'm styling a page right now (developing using libsass), and I'm making changes to font-families, headers etc. For a lot of these changes, I notice that they can be altered in _settings.scss.
My question is, should I be making a bunch of changes to _settings.scss and also adding custom styles to app.scss? Its apparent that app.scss is really intended for app specific changes, but is _settings.scss also intended to be uses this way?
I recommend using _settings.scss as much as you can and create extra scss files for modules and include these in app.scss.
You should customize Foundation through _settings.scssIt's well documented with comments and since the settings can influence multiply css classes, it's the best way to achieve consistency.
I'm currently working on new projects and I'll be using the Foundation 4 Framework (foundation.zurb.com). I checked the web up and down but couldn't find a project (GitHub or otherwise) that ported the SASS logic of Foundation 4 to LESS.
I really like Foundation 4 and I would love to work with SASS but as reality forces me to not use ruby for development, I'm down to using the pure CSS version of Foundation 4. I would prefer to use it with less, which I can easily include in my PHP workflow and porting all the SASS goodness to LESS is quite a bit of work. I am fully aware that some parts of the Foundation SASS logic won't work with LESS, but that is a price I'm willing to pay.
I found a grunt project (github.com/jonschlinkert/grunt-refactor) that offers/promises some degree of porting logic but as I never worked with grunt/node.js before, I couldn't get that working until now.
Do you know of a Foundation 4 LESS port?
Someone tried to create a fork in Foundation3 that was done in LESS but they eventually dropped it. You can find full discussion about this here: https://github.com/zurb/foundation/issues/370. I don't know about any other porting to LESS attemps.