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
Related
I'm working with some SASS code, written for ruby-sass v3.2. In some of the stylesheets, property declarations are written like:
.something
:height 10em
:width 100%
:font-size 1.5em
This compiles and appears to be valid, but I can't find reference to it anywhere. Is this just a quirk of Ruby parsing them as symbols, or something in SASS I've never seen before?
I had to use Wayback Machine to find the "official" information, and it seems that it is just the old SASS way to write a declaration:
Property Syntax
The indented syntax supports two ways of declaring CSS
properties. The first is just like CSS, except without the semicolon.
The second, however, places the colon before the property name. For
example:
#main
:color blue
:font-size 0.3em
By default, both ways may be used. However, the :property_syntax option may be used to specify that
only one property syntax is allowed.
I also found some others mentions of this syntax here:
Using colon syntax and variables in Sass
Convert Sass stylesheets from the old colon syntax
Deprecate old-style property syntax
Edit : there is also an online reference about this here.
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.
When maintaining and updating the mixins for a large team of developers, is it possible to deprecate mixins so that they throw some sort of warning when the styles are compiled?
I do not simply want to remove the deprecated mixins as it will take some time to remove all the current uses, but it'd be nice to warn the other developers that this is being removed if they attempt to use it.
You can use the #warn directive for this. From the SASS documentation:
The #warn directive prints the value of a SassScript expression to the standard error
output stream. It’s useful for libraries that need to warn users of deprecations or
recovering from minor mixin usage mistakes.
You'd use it like this:
#mixin old-mixin {
#warn "This old mixin is deprecated!";
// mixin definition here
}
Lately when using Sass, I have been extending classes as a substitute for variables.
For example:
-Using a variable
$small-font: 12px
p {
font-size: $small-font
}
-Extending a class
.small-font {
font-size:12px;
}
p {
#extend .small-font;
}
The advantage of extending classes is that it makes it easier to make your code responsive. For example, I can wrap .small-font in a media query, which wouldn't be possible with a variable.
My question is: Are there any disadvantages to using extended classes in this way?
I know the output tends to lump all the classes together (which can make debugging more cumbersome), but are there any other potential problems?
There are a few issues. One is simply the crazy-slippery-slope nature of it. This will come back to bite you as a maintenance issue. A class-per-property just doesn't make sense as a code organization scheme. That doesn't mean you're far off - #extend is great for something like this, within reason.
Reason is the key: your groupings should make sense as groupings. While html-style content-semantics are not important with #extends, there should still be a sense of semantic organization. I've seen the term "visual-semantics" floating around for this. Your naming should go beyond describing the effect, and describe the visual reason for it instead. not %yellow, but %highlight-text. Not %red, but %warning. Not what, but why.
The other problem is the cascade. The order of your output code is very important, because it affects the cascade (which is an essential part of CSS). With this approach, you will find yourself fighting against the cascade on a regular basis - because you are giving up control of the code order. #extend is great for broad and simple default groupings, but it isn't any good at cascade overrides.
=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.