So, let's say I have a SASS module _module.scss that declares some css variables aka custom properties. When I now load this module in another SASS styleshee, let's call it main.scss, I have access to all SASS-variables, mixins and also rules, but not the custom properties inside of it? Am I missing something?
Example files:
//_module.scss
:root {
--some-variable: red;
}
// main.scss
#use 'module';
div {
background-color: var(module.--some-variable); // won't work, private property because of leading '-'
background-color: module.var(--some-variable); // won't work, would have been horrible syntax as well
}
I could use #import but that is discouraged and deprecated (see SASS Documentation). I've tried including the variables in a pure css file module.css, which compiled but didn't declare any custom properties at runtime as it directly translates the #use 'module' from my SASS file to the exact same in CSS - which browsers don't understand obviously. It should just more or less copy the content of a pure css file but it doesn't. Sure, I could try writing mixins in my modules that set the variables but that's just a workaround.
Am I missing something? Do I really need to write a mixin, that sets the variables and needs to be loaded? This makes the use of custom properties within modules pretty cumbersome.
EDIT
Forgot to mention, that background-color: var(--some-variable) doesn't work either even though it should according to the documentation, since rules should just be applied directly without scoping.
Ugh. The issue is most definitely the fact that my VS Code extension uses LibSass and not Dart Sass. Therefore #use is not yet supported in most environments. The documentation should most definitely be more explicit about this especially when warning about the use of #import.
Since I know it works with #import the issue is resolved though I'd love to see the module system being included in LibSass as well.
tl;dr
Do no use #use if you're not absolutely certain that you use Dart Sass!
Related
I am gonna use css global variables in scss file so that I can change the button colour in any time.
I want to do like this:
:root {
--button-color: #FF0000;
}
$button-color: var(--button-color);
...
But this makes the issue now.
SASS variables are compile time and final value depends on all files were #import in line. CSS variables are run-time and are calculated based on cascade(say if any parent element redeclares variable - it will be applied to children).
Also take a look into docs section on difference between
You can use css-vars to compile SASS variables into CSS custom properties. But you still cannot use CSS custom properties in SASS code, say, to calculate some value - since CSS property is not initialized yet.
Even with css-vars plugins, things are rather messy, because SASS files does not describe how component tree looks like finally so we cannot see cascade.
TL;DR; don't mix SASS variables and CSS custom properties. Use first for compile-time variables/calculation only and use latest one for run-time/cascade-based styling. Probably prefer using CSS custom properties only.
I have a global CSS file that contains all generic CSS.
I want to be able to extend all the classes present in this global CSS file in any of my SCSS files.
Right now it throws an error .xyz class does not exist and build fails. I tried importing this file but still build fails.
Adding !options next to class is one way for the build to pass but is there any other better way?
Bit more context for Vue users. I use VueCli3. I use <style lang="scss"> for writing SCSS and want to use extend here. Vue documentation suggesting adding prependData for adding variables. I imported the global CSS in a SCSS file and imported that file in the prependData but Vue build still fails.
It sounds like you want to globally include a CSS file with content that the SCSS blocks in each component can read. (Variables, style definitions, etc).
#extend works like a variable, meaning SCSS needs the definition style to be available as part of its compilation. So that means getting "SCSS Global Variables" working should solve your Extend problem too.
In that case, you need to tweak how Webpack deals with your components. You can do it manually as described here. Or my preference is to use a Vue Cli plugin called vue-cli-plugin-sass-resources-loader. Make sure that your component <style> section contains lang="SCSS" though I assume you're already doing that.
Using #import CSS file into SCSS file not possible to #extend any class.
But you can follow below steps for extends class from your pure css code.
Convert .css file into .scss.
import that global.scss file into another .scss file.
Then after you can use #extend for extend class in new file.
If your file have more then 1k line of code then it will get trouble for extend class.
So, let's assume I have the following situation: I have 2 .scss files.
One with a variable, and one that will be actually translated into .css for my webpage, where I want to access to said variable.
vars.scss
$my_color: red;
main.scss
#use 'vars'
body {
color: $my_color;
}
What I am trying to do is to access the variable defined in vars.css and use it.
The reference is correct since if I use #import instead of #use, everything works
I've also tried to reference to the variable with vars.$my_color as was suggested in the documentation, but I keep getting a "undefined variable" error.
Well, if you read the documentation then in the ⚠️ Heads up! section, where the undesirability of further use of the #import rule is written, below, you can read the following:
The #import rule has a number of serious problems:
#import makes all variables, mixins, and functions globally available.
Therefore, the #use rule makes them inaccessible. Which is what you observe in action.
I think to achieve the desired result, combination of #use and #forward rules should be used.
But I am using VSCode Live Sass Compiler (Maybe you're using it too?) where #use is not supported so I couldn't give you the exact howto.
Hope this clarifies a lot.
I have a preprocessor import problem. I have vendor css that i would like to copy functionality. Unfortunately, i don't control the html for this situation either.. so essentially i have vendor css & different vendor html, and i am trying to extend functionality of one css rule into another.
Now, the basic concept in many css preprocessors is to extend the rule.
// Vendor
.foo { font-weight: bold; }
.bar { text-color: red; }
// Mine
.bar { .foo }
In the above example, you don't have access to .foo or .bar, but with preprocessors, you can extend functionality from .foo into .bar, which works great for less/stylus/etc. The problem, is when the vendor rules are only defined in raw css.
So with that said, the most obvious solution is to have Stylus/Less import the raw css as stylus/less. However, neither seem to be able to actually do this.. that i've found at least. Less doesn't seem able to (#import "foo.css" directives are ignored) and while Stylus has an option to actually include the imported raw CSS, it did not seem to actually be processing it. That is to say, it would include the css, but #extend directives failed (perhaps i am wrong?).
The other option i could think of is simply renaming the .css files to the preprocessor language extension. Since we want to keep the vendor stuff out of our hands, allowing for proper versioning/etc, This involves a build process which copies the target css files and renames them into the target language extension, but this is error prone. Stylus ran into syntax errors immediately, and Less could just as easily (as not all CSS is valid Less. most is, but not all).
So.. any additional thoughts on this front? Hopefully there is an option i may be missing? Perhaps SCSS handles this better?
Currently, with what i have found is/isn't possible.. i feel the only stable way is to simply copy the raw css bits into my css code. If the vendor code changes, i'll have to update manually, but at least i don't run the risk of vendor stuff changing and all of a sudden the build process fails, because vendor introduced some CSS syntax not supported by less/etc. It is far from good.. but the worst that can happen is my css looks funny, and i need to update.
edit:
I'm going to try SCSS next.. we'll see how it goes. On the site, they claim all CSS(3 only?) syntax is valid SCSS
edit2: For clarity. My question is, give the above scenario, what would you do? Importing the .css files is not possible (See note below!), and renaming .css files to .less/.stylus can in turn be error prone, since less is not a perfect superset of CSS(namely due to proprietary features).
!Note!: I have since been digging around the less source to see what could be done to fix this problem, rather than work around it, and ran into a dozen support tickets on the matter. The main discussion of which seems to be taking place on #issue 1185, and more importantly, check out the changelog which *(i believe) addresses this issue! CHANGELOG 1.4.0 Beta
So with that said, the #import (less) "file.css" is likely the winning scenario here, even if it may have a few bugs due to the beta status. Yay :)
Your best bet is either what #Lee Olayvar said, or use the new ":extend()" feature in LESS. It sounds like you might have tried the extend feature, but you used the "SASS directive" syntax (which IMO is improper use of an at-rule), whereas LESS uses the CSS-like pseudo-selector syntax:
.foo:extend(.bar) {}
And if you are patient (in the coming days/weeks), you will see a new feature that is perfect for what you want to do, and it's unique to LESS. It will allow you to extend or mixin external "silent" styles. Meaning you will be able to "#import" and external stylesheet but the styles won't show up in your compiled code unless you extend them or use them as a mixin.
I'm on the core team for Less.js btw, so let me know if you have any other questions or if I can be of further help.
It looks like all imported .css files won't be prepocessed by less but will just be added with an #import at the top.
You can import both CSS and LESS files. Only LESS files import statements are processed, CSS file import statements are kept as they are. If you want to import a CSS file, and don’t want LESS to process it, just use the .css extension
Source: http://lesscss.org/
The best thing you could do would be the renaming I believe.
While still in beta, the newly added #import (less) "file.css" syntax should properly handle all CSS files. Due to the "official" support, it can also be expected/assumed that any proprietary syntax that breaks LESS would be fixed (though possibly not "supported").
So in theory this is the best option! Barring SCSS, which i have not tried yet in this scenario. Stylus still has issues though, in my tests.
For more information, check out this issue or this changelog.
The question pretty much says it all.
For instance, if I were using, say, Twitter Bootstrap, could I define classes in my own SASS stylesheet that inherit from Bootstrap's CSS classes? Or does inheritance in SASS only work within the scope of a single file?
YES! its possible.
If you want all <button> elements to inherit the .btn class from Twitter Bootstrap's Default buttons
In your styles.scss file you would have to first import _bootstrap.scss:
#import "_bootstrap.scss";
Then below the import:
button { #extend .btn; }
**I might be mistaken, but if I get what you're trying to do, can't you just use the #extend .classname; command inside the element that you'd want to extend? Naturally, you should only modify your own code to preserve updatability.
To my knowledge, you have to use #import of the file containing the classes you want to use into your SASS file in order to utilize them in that file. However, I am not a SASS/SCSS expert, so someone may know of another way to remotely use them that I am not aware of.
Just as the accepted answer has shown this is possible with #import, however #import has been deprecated by sass
The Sass team discourages the continued use of the #import rule. Sass will gradually phase it out over the next few years, and eventually remove it from the language entirely. Prefer the #use rule instead.
The #use rule is better suited for use now, since it does not pollute the scope of the importing (user) module. unfortunately at the time of writing the use rule is only implemented in Dart sass.