How can I connect these 2 partial folders (variables and base) with my main.scss?
Don't refer me to any video or such, I have watched and tried for the past 3-4 days, nothing working!
Greatly appreciate your help fixing this if you're knowledgeable with sass since I'm not!
That's what the #use rule is for! Adding #use "abstracts/variables"; and #use "base/base"; to your main.scss adds their CSS to yours, and makes their variables, functions, and mixins available with variables. and base. prefixes. You can add as * to the rule (e.g. #use "base/base" as *;) to make them available without prefixes.
This assumes your Sass tool is based on Dart Sass, which most are nowadays. Old tools might be using LibSass, which only supports #import; I recommend using only Dart Sass-based tools whenever possible.
Related
I have multiple SCSS files that I want to import into one main SCSS file. I want ALL of the contents of that file to be imported, basically copying the entire document into the other one. Currently, I am using #import, which is exactly what I need. But now it has been announced that it will be removed from SCSS, and I'm afraid that #use cannot replicate this functionality that I need. With #use, I can only import selected variables, classes etc., but I want the entire file.
Two possible solutions (that I don't want to go for):
A) Writing everything in the same file. But that would become quite messy. I have one template SCSS file with variables and utility classes (a lot of them), and 3 other files for custom code (so the CSS of a site can be changed by multiple people at the same time, having only one file would limit it to one person at a time)
B) Loading multiple stylesheets on the site. That would be the better option, but that would cause a lot of unnecessary requests on the server.
Any ideas? I'm using SCSS in Wordpress. Will the #import rule be unusable once it's been removed from the language? What if I didn't update the Plugin that compiles the SCSS? It's frustrating because the current #import rule does exactly what I need...
Thank you!
The question is more or less resolved. I was trying to migrate from #import to #use in an environment that does not support the #use rule at all. As I said, I'm using a Wordpress plugin to compile. #use is only available in Dart Sass and upon using it in my setup, the compiler would throw errors, as it is based on phpsass, which does not have #use or #forward and still uses #import. Which make everything a lot easier!
I'm moving from Grunt to Gulp and noticed that gulp-sass does not include the contents of files referenced by #import "reset.css" statements. Instead, it normalizes the url reference, as #import url(reset.css). My intention is to have a single CSS reference on my index.html, that would be the concatenation of my CSS dependencies.
It's a simple read-file-and-output-contents operation, but I bet this is already implemented and I just don't know where to find it -- I'm still new on this ecosystem and would not like to spend time reinventing the wheel.
EDIT: the selected answer for this related question uses gulp-minify-css, instead of gulp-sass. Exchanging them could be a short-term solution, but I'd prefer to avoid my new build system to rely on unstable plugins. Moreover, I actually have plans to use scss, so I'd be back to having to deal with gulp-sass again. Thanks for the suggestion, though.
#import should actually include the contents of the file, not make a reference to it. Sounds like maybe the transpiling of the SCSS to CSS isn't working properly.
I'm trying to sift through all the CSS options / packages available for EmberJS and am looking for suggestions. I suppose it will help if I list what I need:
SASS syntax (variables, nesting, creating mixins, and extending)
Ability to import other CSS libraries
Pod support (although I'm not positive I'll be using this feature at the moment, but I at least want to be able to have one CSS per route/component)
Autoprefixer
Is there an all-in-one Ember package that will give me all these? Thanks!
SASS syntax (variables, nesting, creating mixins, and extending)
You should think long and hard before taking the blue SASS pill. SASS is a technology trending towards obsolescence, which was designed mainly to support some bad CSS coding practices, as well as overcome some deficiencies in earlier versions of CSS.
Variables are supported by postCSS plugins in a standard way which is compatible with the upcoming CSS variable syntax.
Nesting is an answer in search of a problem. It promotes a bad style of coding involving excessive dependency on HTML structure. Properly constructed systems of CSS classes, orthogonal to HTML, make nesting unnecessary.
With regards to mixins, I have not seen a real-life situation in which mixins or other more advanced SASS features were actually necessary. Using them, you end up learning yet another (weird) programming language, which you have to debug, and make sure all the people on your team know.
When it comes to extending, CSS experts counsel against it. Besides potential issues of performance and code size, they hide the logic of the CSS code, and require jumping back and forth from file to file to maintain and extend and debug. Everything that is accomplished with extending can be handled with properly-designed CSS classes.
SASS is slow, is bifurcated (binary version vs. Ruby version), and can give rise to strange npm installation problems. My advice is to avoid it.
There is an interesting read about SASS vs. postCSS here.
Ability to import other CSS libraries
Ability to import other CSS libraries is not a function of any other decision you make, or what package you choose. You can simply import these.
Pod support (although I'm not positive I'll be using this feature at the moment, but I at least want to be able to have one CSS per route/component)
Indeed. There is at least one new-ish Ember add-on to do this (and probably more), which IMHO is designed extremely poorly and grossly over-engineered. It follows the Ember approach of doing way too much, in an opaque way, in the name of being "helpful" (until it isn't, at which point you're screwed). This is great if you want your CSS to be littered with classes like .my-component-a34fba.
Until there is a better alternative, I'd do this manually, which is quite easy. Simply place your CSS files in the pod, and then import, from your styles/app.css or equivalent file, the CSS files from the pods you want, such as #import '../pods/thingie/; to import its index.css file. Yes, you will have to do some maintenance of these imports yourself, but how many pods do you have?
What I do to avoid a huge styles/app.css that would require constant updating is to place an index.css file in each pod and import that. From there, import a stylesheet for that directory itself and any necessary subdirectories:
/* styles/app.css */
#import '../app/pods/thingie';
/* app/pods/thingie/index.css */
#import `./style`;
#import `./subdir1';
#import `./subdir2';
Autoprefixer
You need look no further than the excellent postcss/autoprefixer.
Is there an all-in-one Ember package that will give me all these?
It would be nice if all our problems could be handled by all-in-one packages. Unfortunately, all-in-one packages are always missing two features we wanted, and we can never figure out how to add them. They always do one thing we didn't want them to do, and we can never figure how to turn it off. They import old versions of their subpackages. They break when there's an Ember upgrade. They stop being maintained. The Ember philosophy itself sadly promotes this pernicious all-in-one mentality--all my problems can be solved by yet another add-on!
You are better off understanding individual technologies, choosing simple, bounded, reliable implementations of them, and weaving them together yourself. Just my two cents.
This might be the closest thing you're looking for:
https://github.com/ebryn/ember-component-css
Which supports using pods layout, and lets you use ember-cli-sass.
To use auto-prefixing, there are plenty of sass libraries out there to help you out, like Bourbon.io, which you can install via npm. Then, it should just be matter of configuring the import paths via the sass options in the ember-cli-build.js
I recommend PostCSS. Last I checked, it doesn't work out-of-the-box with ember-component-css, but you don't need ember-component-css to namespace your styles.
You can modify Ember's Component generator / blueprint to (assuming you're using pods):
Add classNames: ['component-name-here'], to the generated component.js file.
Create a _component-name-here.css file/partial in app/styles/components (or similar), with a class .component-name-here to contain all styles in the partial.
If necessary, #import that new partial in your app.css.
Then all your Component styles will be namespaced.
To handle variables, nesting and Autoprefixer, you just need to set up PostCSS with the right plugins, e.g.:
plugins: [
{
module: require('postcss-partial-import'),
},
{
module: require('postcss-nested'),
},
{
module: require('postcss-custom-media'),
},
{
module: require('postcss-custom-properties'),
},
{
module: require('autoprefixer'),
options: { browsers: ['last 2 versions'] }
},
],
I'm using ember-cli-css-preprocess, which gives you the option to use SASS as well (alongside PostCSS), if you wish.
I have an issue with sass compilation.
When I have a project with a partial _partial.scss and have it imported in multiple partial files (because it contains color variables) it will end up in the compiled css multiple times!
This is ugly because the same rule will 'overrule' itself multiple times which makes debugging info (chromium dev tools / firebug) rather unreadable.
I presume there is a solution for all this. I just can't find anything on the issue, anywhere.
The solution is to either not include the same file multiple times or don't have any code that directly outputs CSS in the file you're planning on including more than once. If your variables were in a file by themselves, they could be safely included anywhere you'd like without selector duplication.
Maybe this #mixin helps you: https://github.com/wilsonpage/sass-import-once.
Have a look at the example and note how the reset is only included once in the final CSS.
It seems that just for this, sass (and thus, scss) now have #use instead of #import. From the #use documentation (emphasis is mine):
The simplest #use rule is written #use "", which loads the module at the given URL. Any styles loaded this way will be included exactly once in the compiled CSS output, no matter how many times those styles are loaded.
Sass also discourages further use of #import:
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.
Any projects having this problem could try running the module migrator tool and check if the problem is resolved.
Is there a CSS minifier tool that can resolve #import statements?
I'd like to be able to load multiple CSS files on my local machine but have them all resolved into one file when the website gets pushed out into production.
I recently started using LESS, beyond imports allows you to use:
Variables
Mixins
Parametric Mixins
Nested rules
Operations
Color functions
Namespaces
Scope
Comments
Escaping
So far I'm glad with my experience using LESS.
It's easy to use and the page is documented with good examples.
You can use SASS, with the SCSS syntax. SASS is much more than a minifier: it is actually a CSS preprocessor which adds some goodies like variables or macros to the CSS syntax. But you can choose to simply ignore these features (although I advise you to have a look): any valid CSS file is actually valid SCSS.
SASS can then compile your SCSS in valid CSS, and it can manage multiple files and output a single minified .css file.
You can try it just as a minification tool for now, and start using the advanced features when you feel like experimenting.
css-compressor (based on yuicompressor) inlines #import statements - in fact that is its primary purpose:
https://github.com/samilyak/css-compressor
Granule library supports #import in CSS.
You can look it here http://code.google.com/p/granule/