Hello. I'd like to import variables to my website's sass file but after adding:
@import "../bower_components/materialize/sass/components/_variables.scss";
I'm getting following error:
Error: $color: 'color("materialize-red", "lighten-2")' is not a color for `lighten'
on line 37 of /opt/lampp/htdocs/materialcv/static/bower_components/materialize/sass/components/_variables.scss
from line 10 of /opt/lampp/htdocs/materialcv/static/sass/page.scss
If I import materialize colors component before variables it all will work well. The problem is I don't want to include colors for the second time becuase they are already included in materialize. They are 1.6k lines trash in my output css file
Sass 3.4.21 (Selective Steve)
materialize#0.97.7
I also copy color.scss and remove function witch output colors classes to CSS, I thin what this function need sperate file. Because it is usifle to reuse color function to calculate color
My solution was to create a new partial - components/_palette.scss. - and move all the lists (i.e. $materialize-red: (... and the @function color() definition in _color.scss to the new file. Now, all _color.scss does is create css classes.
In materialize.scss the line @import "components/palette"; was added above @import "components/color"; The result is that Materialize compiles as it should.
Now, to use Materialize variables in a site's css: (without duplicating the color classes) do this.
@import "components/palette";
@import "components/variables";
materialize#0.97.7
If you want a pull request let me know.
Yes, we want a pull request :-)
Wrapping the function that creates these colors in a variable could solve the problem.
We would have to split the current _colors.scss file into two files: _colors.scss and _color-palette.scss.
The palette would only contain the palette and the sass function, that allows you to access the colors via color("name_of_color", "type_of_color"). The _colors.scss file would only contain the if statement, that optionally generates all the colors and the primary/secondary classes.
With these changes, you could easily access the palette by importing it before anything else.
E.g.:
_variables.scss:
// Setting this to false will prevent materialize from generating classes for all colors from the color pallette.
// We highly recommend to set this to false when going into production!
$generate-color-classes: true !default;
_colors.scss:
@if $generate-color-classes == true {
// Generate colors...
}
In addition to that, I think it would make sense to provide classes that apply the primary and secondary class:
// Primary and Secondary
.primary {
background-color: $primary-color !important;
&-text {
color: $primary-color !important;
}
}
.secondary {
background-color: $secondary-color!important;
&-text {
color: $secondary-color !important;
}
}
I like the idea. What I'm currently doing in my projects is that I copy all the imports from materialize.scss file and then override _colors.scss array of colors. This would be much much easier and it would be maintainable but still not break the default behavious for those that import the compiled css from cdnjs or somewhere else.
Most helpful comment
Wrapping the function that creates these colors in a variable could solve the problem.
We would have to split the current
_colors.scssfile into two files:_colors.scssand_color-palette.scss.The palette would only contain the palette and the sass function, that allows you to access the colors via
color("name_of_color", "type_of_color"). The_colors.scssfile would only contain the if statement, that optionally generates all the colors and the primary/secondary classes.With these changes, you could easily access the palette by importing it before anything else.
E.g.:
_variables.scss:
_colors.scss:
In addition to that, I think it would make sense to provide classes that apply the primary and secondary class: