My confusion comes from (aside from being relatively new) the term "Sass" being used to refer to both Sass and SCSS syntax.
Based on this guide, they are distinct: http://sass-lang.com/guide
So when reading a discussion, or a job listing, unless syntax is provided I am not sure which dialect they are talking about.
Has Sass syntax been replaced by SCSS syntax (or vice-versa) and just falls under the umbrella term "Sass"?
Just want to make sure I have been using and learning is the current syntax. I have been learning the SCSS syntax.
SASS is SASS, SCSS is SASS.
They are practically the same thing, except the main differences between them being that SASS does not require curly braces or semi-colons and some find this a bit daunting at first, so the good people behind it created SCSS, which likes its curly braces { } and semi-colons ; .
SASS
section
header
width: 100%
height: 40px
SCSS
section {
header {
width: 100%;
height: 40px;
}
}
More detailed information about this can be found at the main SASS website.
And ofcourse, the file-extension being changed from *.sass to *.scss so that one can be aware of the fact.
These are the main differences, there are other bits and nits but the choice between both comes down to personal preference or project requirements.
Verdict: If you know SASS, you know SCSS.
Related
i feel like this may be simple enough and I'm just missing it. I recently went to 7-1 folder structure instead of a single scss file. What i'm having difficulty with is referencing .panel(or h2 or span) in _typography.scss to do font-styling and reference the same .panel(h2,span, etc) in my _layout.scss.
I understand from a CSS pov this wouldn't be logical to have them broken up as of sequencing, however, from a sass pov, I feel like there should be a way to structure this so my CSS doesn't have .nav-container mentioned twice.
Just to note, I'm using NPM, not an ide compiler. Maybe I'm just going about structuring generally incorrect and shouldn't separate them.
Please advise,
UPDATE ANSWER
I've marked Frish's answer here correct because the way that they set it up is correct, but after several and i mean several days of research, i've decided to add some context as I see many others have created simiar threads.
The way I initially looked at SASS was incorrect. I was trying to make SASS work in a way i thought would eliminate complexity: (having .nav-container {} typography rules in a typography partial, then .nav-container {} layout in a layout partial.) This isn't the right way of thinking.
The real benefits are all the built in functions (placeholders,mixins, extends) that drive the magic of making SASS more effective.
However, there is a way to still do what you're looking to do, styling selectors across different partials, for example, separating typography styling from layout styling, and so forth, for particular selector. This was a major wakeup call. Passing Style Blocks (or Content Blocks) to a mixin or whatever. So for example:
#mixin button {
font-size: 1em;
padding: 0.5em 1.0em;
text-decoration: none;
color: #fff;
#content;
}
.button-green {
#include button {
background: green
}
}
Finally,
this link(https://openclassrooms.com/en/courses/5625786-produce-maintainable-css-with-sass/5951856-write-cleaner-code-with-sass-extensions) is where it really clicked for me
Look at the section paragraph that starts with "extensions are a lot like mixins." Review this example as it should be easy to apply its setup and way of structuring to what you're trying to do.
Getting deeper into this, i did some googling on "passing style blocks" and "sass passing content blocks" and that helped a ton on how to leverage placeholders, mixins, and extends effectively while still maintaining the simplicity of sass structuring.
This isn't a concrete answer as there are many ways to approach this (as you are undoubtedly aware), but here are my thoughts.
I typically use generic stylesheets (_typography, _layout) for generic elements (h1,h2,h3, .section, .container perhaps). Any element that merits special mention in multiple files potentially merits being its own component (e.g. panel.scss).
This does increase the numbers of folders and files floating around, but I still find this preferable to one, or a few, big files. I usually end up with a main.scss file that looks like this:
// main.scss
#import "_variables.scss";
#import "_typography.scss";
// etc....
#import "./components/panel.scss";
#import "./components/navContainer.scss"; // or, nav-container.scss!
// etc....
Components happily override generic styles, and I can track their CSS in individual files. Happy dev! You can sub-divide components or other files as you see fit.
I find SASS syntax much easier and cleaner than SCSS, but the documentation is not as widespread and complete so I often stumble in time wasting syntax errors. Many articles mentioning SASS actually only contain information about SCSS. Even the official SASS documentation (https://sass-lang.com/documentation/file.SASS_REFERENCE.html#if) contains examples that apparently only refer to SCSS. For example, what's the SASS syntax for conditional statements in mixins? For example:
=button-colors($primary, $secondary, $border: true)
background-color: $primary
color: $secondary
if $border
border-color: $secondary
else
border-color: $primary
This example does not compile correctly: the if statement is ignored and there's no border-color in the resulting CSS.
Does anybody know about useful websites with documentation and examples of SASS syntax or tools to convert from CSS/SCSS to SASS online?
As you saw, The reference document is written in scss syntax maybe because of its more popularity and I'm going to highly recommend you choose scss syntax because of its most benefits that maybe is not clear at first view!
But anyway if you prefer to use sass one, I think you have to follow main document and check this link to watch the differences and then correct your syntax.
You can also use these tools to convert stylesheets:
css2sass: css to scss/sass.
sassmeister: scss/sass to css.
I know CSS very well, but am confused about Sass. How is SCSS different from CSS, and if I use SCSS instead of CSS will it work the same?
In addition to Idriss answer:
CSS
In CSS we write code as depicted bellow, in full length.
body{
width: 800px;
color: #ffffff;
}
body content{
width:750px;
background:#ffffff;
}
SCSS
In SCSS we can shorten this code using a #mixin so we don’t have to write color and width properties again and again. We can define this through a function, similarly to PHP or other languages.
$color: #ffffff;
$width: 800px;
#mixin body{
width: $width;
color: $color;
content{
width: $width;
background:$color;
}
}
SASS
In SASS however, the whole structure is visually quicker and cleaner than SCSS.
It is sensitive to white space when you are using copy and paste,
It seems that it doesn't support inline CSS currently.
$color: #ffffff
$width: 800px
$stack: Helvetica, sans-serif
body
width: $width
color: $color
font: 100% $stack
content
width: $width
background:$color
CSS is the styling language that any browser understands to style webpages.
SCSS is a special type of file for SASS, a program written in Ruby that assembles CSS style sheets for a browser, and for information, SASS adds lots of additional functionality to CSS like variables, nesting and more which can make writing CSS easier and faster.
SCSS files are processed by the server running a web app to output a traditional CSS that your browser can understand.
css has variables as well. You can use them like this:
--primaryColor: #ffffff;
--width: 800px;
body {
width: var(--width);
color: var(--primaryColor);
}
.content{
width: var(--width);
background: var(--primaryColor);
}
Variable definitions right:
$ => SCSS, SASS
-- => CSS
# => LESS
All answers is good but question a little different than answers
"about Sass. How is SCSS different from CSS" : scss is well formed CSS3 syntax. uses sass preprocessor to create that.
and if I use SCSS instead of CSS will it work the same? yes. if your ide supports sass preprocessor. than it will work same.
Sass has two syntaxes. The most commonly used syntax is known as “SCSS” (for “Sassy CSS”), and is a superset of CSS3’s syntax. This means that every valid CSS3 stylesheet is valid SCSS as well. SCSS files use the extension .scss.
The second, older syntax is known as the indented syntax (or just “.sass”). Inspired by Haml’s terseness, it’s intended for people who prefer conciseness over similarity to CSS. Instead of brackets and semicolons, it uses the indentation of lines to specify blocks. Files in the indented syntax use the extension .sass.
Furher Information About:
What Is A CSS Preprocessor?
CSS in itself is devoid of complex logic and functionality which is required to write reusable and organized code. As a result, a developer is bound by limitations and would face extreme difficulty in code maintenance and scalability, especially when working on large projects involving extensive code and multiple CSS stylesheets. This is where CSS Preprocessors come to the rescue.
A CSS Preprocessor is a tool used to extend the basic functionality of default vanilla CSS through its own scripting language. It helps us to use complex logical syntax like – variables, functions, mixins, code nesting, and inheritance to name a few, supercharging your vanilla CSS. By using CSS Preprocessors, you can seamlessly automate menial tasks, build reusable code snippets, avoid code repetition and bloating and write nested code blocks that are well organized and easy to read.
However, browsers can only understand native vanilla CSS code and will be unable to interpret the CSS Preprocessor syntax. Therefore, the complex and advanced Preprocessor syntax needs to be first compiled into native CSS syntax which can then be interpreted by the browsers to avoid cross browser compatibility issues. While different Preprocessors have their own unique syntaxes, eventually all of them are compiled to the same native CSS code.
Moving forward in the article, we will take a look at the 3 most popular CSS Preprocessors currently being used by developers around the world i.e Sass, LESS, and Stylus.
Before you decide the winner between Sass vs LESS vs Stylus, let us get to know them in detail first.
Sass – Syntactically Awesome Style Sheets
Sass is the acronym for “Syntactically Awesome Style Sheets”. Sass is not only the most popular CSS Preprocessor in the world but also one of the oldest, launched in 2006 by Hampton Catlin and later developed by Natalie Weizenbaum.
Although Sass is written in Ruby language, a Precompiler LibSass allows Sass to be parsed in other languages and decouple it from Ruby. Sass has a massive active community and extensive learning resources available on the net for beginners. Thanks to its maturity, stability and powerful logical prowess, Sass has established itself to the forefront of CSS Preprocessor ahead of its rival peers.
Sass can be written in 2 syntaxes either using Sass or SCSS. What is the difference between the two? Let’s find out.
Syntax Declaration: Sass vs SCSS
SCSS stands for Sassy CSS. Unlike Sass, SCSS is not based on
indentation.
.sass extension is used as original syntax for Sass, while SCSS
offers a newer syntax with .scss extension.
Unlike Sass, SCSS has curly braces and semicolons, just like CSS.
Contrary to SCSS, Sass is difficult to read as it is quite deviant
from CSS. Which is why SCSS it the more recommended Sass syntax as it
is easier to read and closely resembles Native CSS while at the same
time enjoying with power of Sass.
Consider the example below with Sass vs SCSS syntax along with Compiled CSS code.
Sass SYNTAX
$font-color: #fff
$bg-color: #00f
#box
color: $font-color
background: $bg-color
SCSS SYNTAX
$font-color: #fff;
$bg-color: #00f;
#box{
color: $font-color;
background: $bg-color;
}
In both cases, be it Sass or SCSS, the compiled CSS code will be the same –
#box {
color: #fff;
background: #00f;
Usage of Sass
Arguably the most Popular front end framework Bootstrap is written in Sass. Up until version 3, Bootstrap was written in LESS but bootstrap 4 adopted Sass and boosted its popularity. A few of the big companies using Sass are – Zapier, Uber, Airbnb and Kickstarter.
LESS – Leaner Style Sheets
LESS is an acronym for “Leaner Stylesheets”. It was released in 2009 by Alexis Sellier, 3 years after the initial launch of Sass in 2006. While Sass is written in Ruby, LESS is written JavaScript. In fact, LESS is a JavaScript library that extends the functionality of native vanilla CSS with mixins, variables, nesting and rule set loop. Sass vs LESS has been a heated debate. It is no surprise that LESS is the strongest competitor to Sass and has the second-largest user base. However, When bootstrap dumped LESS in favor of Sass with the launch of Bootstrap 4, LESS has waned in popularity. One of the few disadvantages of LESS over Sass is that it does not support functions. Unlike Sass, LESS uses # to declare variables which might cause confusion with #media and #keyframes. However, One key advantage of LESS over Sass and Stylus or any other preprocessors, is the ease of adding it in your project. You can do that either by using NPM or by incorporating Less.js file.
Syntax Declaration: LESS
Uses .less extension. Syntax of LESS is quite similar to SCSS with the exception that for declaring variables, instead of $ sign, LESS uses #.
#font-color: #fff;
#bg-color: #00f
#box{
color: #font-color;
background: #bg-color;
}
COMPILED CSS
#box {
color: #fff;
background: #00f;
}
Usage Of LESS
The popular Bootstrap framework until the launch of version 4 was written in LESS. However, another popular framework called SEMANTIC UI is still written in LESS. Among the big companies using Sass are – Indiegogo, Patreon, and WeChat
Stylus
The stylus was launched in 2010 by former Node JS developer TJ Holowaychuk, nearly 4 years after the release of Sass and 1 year after the release of LESS. The stylus is written Node JS and fits perfectly with JS stack. The stylus was heavily influenced by the logical prowess of the Sass and simplicity of LESS. Even though Stylus is still popular with Node JS developers, it hasn’t managed to carve out a sizeable share for itself. One advantage of Stylus over Sass or LESS, is that it is armed with extremely powerful built-in functions and is capable of handling heavy computing.
Syntax Declaration: Stylus
Uses .styl extension. Stylus offers a great deal of flexibility in writing syntax, supports native CSS as well as allows omission of brackets colons and semicolons. Also, note that Stylus does not use # or $ symbols for defining variables. Instead, Stylus uses the assignment operators to indicate a variable declaration.
STYLUS SYNTAX WRITTEN LIKE NATIVE CSS
font-color = #fff;
bg-color = #00f;
#box {
color: font-color;
background: bg-color;
}
OR
STYLUS SYNTAX WITHOUT CURLY BRACES
font-color = #fff;
bg-color = #00f;
#box
color: font-color;
background: bg-color;
OR
STYLUS SYNTAX WITHOUT COLONS AND SEMICOLONS
font-color = #fff
bg-color = #00f
#box
color font-color
background bg-color
And this is less
#primarycolor: #ffffff;
#width: 800px;
body{
width: #width;
color: #primarycolor;
.content{
width: #width;
background:#primarycolor;
}
}
Sass is a language that provides features to make it easier to deal with complex styling compared to editing raw .css. An example of such a feature is allowing definition of variables that can be re-used in different styles.
The language has two alternative syntaxes:
A JSON like syntax that is kept in files ending with .scss
A YAML like syntax that is kept in files ending with .sass
Either of these must be compiled to .css files which are recognized by browsers.
See https://sass-lang.com/ for further information.
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.
I've just started using SASS. Very impressed, however there is something I'd like to do but can't seem to find answer as whether or not it's possible.
I have a block of CSS that I don't want SASS to parse/compile but I would still like that block outputting to the final compiled CSS file. Is this possible?
Thanks.
My first ever SO question, normally provides the answer. Hope I've not missed it somewhere, tried every search term I could think of to find it.
Put it in a separate .css file and import it in your SASS file. File ending in .css are not parsed but are still included in the final output.
This question is a bit old, but, in the spirit of keeping things up-to-date:
The current version of SASS (3.4.22) does a pretty good job of only changing what it needs to. If what you've written is valid CSS, it should output as is.
The only times you should see SASS modifying your styles is if you've done something that looks like it's supposed to be modified. Based on their documentation, that would be things like:
Nesting styles
Concatenating strings
content: 'foo' + 'bar';
Using interpolation
left: calc(50% - #{$variable})
Using variables
width: $variable
Using #extend or nesting an #include
In most other situations, in my experience, SASS will happily spit out whatever you've written.
If you do need to output something that SASS insists on parsing when it doesn't need to, you can wrap the offending piece in quotes and remove them using the unquote function:
$family: unquote("Droid+Sans");
#import url("http://fonts.googleapis.com/css?family=#{$family}");
which compiles to
#import url("http://fonts.googleapis.com/css?family=Droid+Sans");
Try to enclose your block in /* ..... */ in your scss file. Hope it helps.