I have inherited a site from a development team long gone that used scss to compile the style sheet. Unfortunately the documentation on how to set up the development environment is non-existant and whilst I have everything else going on the site, the scss / sass compiling process is taking it's toll on my sanity. I have the following code and various iterations of this pattern throughout the codebase:
#include breakpoint($bp-medium) {
background-color: transparent;
width: (100 / 3) + %;
}
The "+ %" at the end of the width statement is being complained about by the compiler. If I remove it from the formula it compiles fine, but I'm trying to understand what the original intent here was. Can someone give me some explanation of (what I expect is) old syntax from a few years ago and what the current sass/scss compiler would expect to see to achieve the same result?
I've installed Ruby Sass v3.7.4, and I have deployed bourbon (and fixed up the imports) and neat (and also fixed up the import statements). I suspect I'm going to end up bashing my head some more on the screen... but any pointers here would be appreciated.
(100 / 3) + %
is meant to represent the third of 100 in percentage.
You can do something like this:
$width: percentage(100 / 3);
and then use $width.
Related
I'm trying to create a variable that will switch styles by changing it's value.
something like:
$style: 1;
$color1: #f60;
$color2: #096;
$color: $color#{style};
.a{
color: $color;
}
Unfortunately the result is: Undefined variable: "$color".
Could someone explain to me why this doesn't work?
Seems like this feature got added in SASS 3.3
When we released Sass 3.02, we added support for SCSS, which meant we had to actually parse all the selectors in the document. This meant that you couldn't just plop the parent selector, &, anywhere in a selector. Overall this was an improvement: it caught more errors and encouraged users to write more flexible mixins.
Unfortunately, it also made one important use-case harder. With the rise in popularity of BEM, OOCSS, and SMACSS, people became more and more interested in adding suffixes to classes. When using Sass, they wanted to write mixins to do this, and the restrictions on & made that very hard to do.
In Sass 3.3, we're loosening these restrictions. You can now write &-suffix (or &_suffix, or even &suffix if you really want) and Sass will make it work. If this fails to apply—for example, if & is * —Sass will print a helpful error message.
source
This question already has answers here:
Adding a unit to a number in Sass
(2 answers)
Closed 6 years ago.
Simple one this (hopefully with a simple solution).
Sass is compiling this....
font-size:(30/13)em;
into this....
font-size: 2.30769 em;
The space before the em makes it invalid and Chrome ignores it.
Any ideas?
(oh and before anybody asks why I'm dividing one number by another, I've simplified a formula to make the question simpler, normally there would be variables in there).
Hmm, I think you can use:
font-size:(30em/13);
to fix this. (At least, that's what compiles properly in Sass for me.) Although, if you're using variables, that could change things (if you can't have the em inside of the variable).
In which case, you could try:
font-size:$var*1em;
Which works out when Sass compiles it on my machine.
I have something like this in one of my SCSS include files:
$inputBorderRadius: 0 !default;
.input {
#include border-radius($inputBorderRadius);
}
This works fine; I can override the $inputBorderRadius before including the above code and everything behaves the way I expect.
What I'm wondering is whether there's a way to tell SASS not to generate the border-radius rule at all if (for example) $inputBorderRadius is null. In my case, I just don't want to generate superfluous rules like border-radius: 0 that specify the default.
I am aware of the #if directive, but the documentation says:
Note that control directives are an advanced feature, and are not recommended in the course of day-to-day styling.
Am I thinking about this all wrong? I'm fairly new to SASS, so I hope this isn't too much of a n00b question.
You just want to use the null value in place of 0. Null is available now in Sass 3.2, and doesn't output the property when it is the only value.
You can also take that warning more lightly. You don't want to get carried away with control directives in normal use, but they aren't going to hurt anything when you need them. There's a helpful if($test, $true, $false) function for the simpler cases as well.
In the official webpage they say:
Although no longer the primary syntax,
the indented syntax will continue to
be supported.
Doe anybody know why SCSS "partially took over" SASS?
The concepts that Sass addresses aren't obvious to designers, and this means that Sass has always been misunderstood as nothing more than a different, quirky syntax for writing CSS.
(LESS.css has gained a little buzz among designers, probably because its syntax is more similar to CSS — even though Sass is more capable and robust, regardless of syntax.)
Because Sass is a language for authoring styleshets, it needs to be approachable to designers. The whitespace-aware Sass syntax is perceived as a "completely different" language with little functional gain, and the different syntax isn't everyone's cup of tea. The valuable concepts like variables, mixins, subclasses (#extends), unit arithmetic, color math, etc. go right over people's heads if they can't get past the "weird" syntax.
SCSS was designed to be a true superset of CSS. This means anyone can start with a plain CSS file and their knowledge of CSS, and then introduce concepts gradually without being overwhelmed.
The sass-convert utility makes the choice of syntax a moot point: if you prefer Sass over SCSS like I do, it's easy to switch.
=rounded(!rad)
:-moz-border-radius = !rad
:-webkit-border-radius = !rad
:border-radius = !rad
I have this mixin defined in a .sass file. When I try to compile it with sass style.sass style2.css, I get this error:
Syntax error on line 2: Undefined constant: "!rad".
I've looked through the docs and can't find what I am doing wrong. If I reduce the sass file to just this section, the error still happens. I am not using it with Ruby/
That mixin looks absolutely correct to me. Is that in style.sass or style2.sass? I'm guessing you're defining it in one, and using it in the other.The first thing to check would be that when you're mixing it in, you're not forgetting to pass an argument. For instance:
.round_div
+round // will not work
Instead of
.round_div
+round(1em) // should work
If that's not the case, try updating Sass. The ability to pass arguments to mixins was added in 2.2.0.
I've got a gist a put up a few days ago for a slightly more complex version of the same mixin. It's working fine for me as long as I mix it in with an argument, and have a new enough version of Sass.