Open RopoMen opened 8 years ago
Hi!
We want to offer "smart defaults" with the atoms by themselves (so that you don't necessarily need _variables.scss or you can just add variables that you like to customize and otherwise rely on defaults). Idea behind it, is to modularize Once even more. But we might need to revisit that idea..
Prefixes on the variable names is a good idea!
Hi,
Yes there is alot of different ways of using frameworks and how I use css frameworks goes like this.
bower_components
something.myproject.scss
I will use following structure@import "_my-variables.scss";
@import "_my-bootstrap.scss"; // import paths in this file points under `bower_components`
What I gain in this structure?
_my-variables.scss
and I can override framework specific variables over there as long as framework has used !default
definition. This is clear place where configuration is done._my-bootstrap.scss
. This structure also easily enables enabling some of the components AND you can easily see what components framwork offers.bower update bootstrap-sass
or so. (I only need to check if some new components are added and add those import lines to my own "proxy" file)For my self at least it is easier to add that kind of "proxy" import file which gives simple way to controll included framework instead of importing one framework file at the time when I need those. I only care how small compiled css my project provides not how many sass files I need to import to do that. Effort to make that "proxy" is something like 1 minute compared to adding that single import statement 5 seconds, but if you look that in "project time" those are equal.
Also last notes for Foundation and Bootstrap;
_variables.scss
_global.scss
and component specific variables which are defined inside components sass file.Yes, it's a good practice and basically what you may do with Once as well (I do it currently too :) )
But we were considering to take this further and make atoms perhaps their own packages (or at least kind of self-contained), so that people could build their own 'plugins', get different versions and maintain atoms easier. That would mean centralized variables.scss is not that easily possible, since we couldn't know about all the possible plugins, and wouldn't want to add huge amount of possibly unwanted variables for the project. But at the same time allowing users to use centralized variables.scss if they want.
Project is not there yet though, so it's a bit difficult to see at this stage, but hoping to get there.
Hi,
Why not just define breakpoints like that in _variables.scss ? $breakpoints: (xs: 320px, sm: 640px, md: 1024px, lg: 1200px)!default;
then you don't need to define those breakpoints in each and every scss file and those still can be override by others.
Also prefixing variables would add more security if these files are added in to project which contains some other framework and its variables. $once-breakpoints etc.