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.
Related
We use SonarQube against our application. One of the SonarQube rules says:
Selectors of lower specificity should come before overriding selectors of higher specificity
The details are here. As my application has many violations, changing the order by hand isn't really feasible. I'm wondering if there's a way to use scss-lint, stylelint or something else in a "fix" mode that could change the order of the selectors. I looked but couldn't find anything in stylelint. Maybe it can't safely be done automatically, as changing the order could affect specificity and therefore change the application behaviour...
As I personal! know there is no Linter which provide that. (I am curious about it.) But just some thoughts about the need of following that 'rule':
Indeed: writing SASS/CSS the way Selectors with lower specifity comes first is a good practicse. The CSS structure becomes more readable and it is easier to build up your code structure as there is a clearer systematic in your head (and the code).
But just up from the mechanic CSS works there is REALLY NO NEED to do it this way. The code simply doesn't become safer doing so or less safe and the pages don't load slower not doing it. That is what the mechanic of specifity has been done for: as of the specifity not the order of the selectors counts and you are able to write your code in the order you need it. Only if the specifity is the same the order counts.
So, maybe this rule leads to 'better' code. But: NOT ALL RULES NEEDS TO BE FULLFILLED. Not all rules Google tries to establish with their best practice rules they offer in their browser, nor all rules other analysis tools provide needs to be followed.
And if not in this project as it needs resources to correct it ... it maybe could but has not be a target for next project ;-)
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
In the singularity demo, there are a few samples using a push and pull mixin. When used they adjust content placement across the gutter. Looking high and low, I could not find any documented reference to these mixins. Are they part of the long term feature set or a leftover? If not, what is the recommended way to do this sort of gutter shift?
Found the answer here
Push/Pull are currently non-documented features that are being deprecated in Singularity 1.2.0. They make sense when using float output method and symmetric grids, but don't make sense for any other combination we can think of. Instead, we recommend utilizing the isolation output style (or, if you're feeling adventurous, the new calc output style in Singularity Extras)
The other option is to write your own mixin with the use of the grid-span, column-span, and gutter-span functions.
Having read about the deprecation of push/pull in Ver 1.2.0, I have just swapped my pull spans for isolation spans. It was so easy, I can't imagine why I hadn't used that method before. A lot of Singularitygs has to be learnt by trial and error, but perhaps the next set of docs will be better. I have also seen that they are removing the grid-overlay and grid-toggle from Ver 1.2.0. That's a shame. I got them working beautifully despite the lack of documentation. Still, the background-grid works well.
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.
Is it possible to write your own gnatcheck rules, and if so, can someone point me to a good reference? I am searching for a particular "style" that is being used, and would love if I could simply write a rule that says if you see said style, it will throw up a warning, or an error, this way we can flag when this isn't following a particular standard.
A bit of background may be helpful here. While the style checks hold out a lot of promise for enforcing user style guidelines, that isn't exactly what they are for.
The main purpose of those checks is to enforce Ada Core's (The folks who maintain the compiler) style on the sources of the Ada compiler itself. You may notice that the checks get automatically turned on if you try compiling one of the compiler's own source files.
It doesn't really serve AdaCore's purposes at all if the styles enforced by the checks themselves are user-configurable, so they added no feature like that.
Your first option if you want to use it yourself is to just stick to AdaCore's coding style. I haven't found it horrible in the past, so you may just look at doing that.
Still, making some kind of configurability would be a really cool feature for somebody to add. If you go this route, you probably would have to make it configurable (with the current behavior as the default), rather than just changing the checks. The reason is that you'd have to modify the compiler sources to accomplish this, and as I mentioned above, the compiler turns the checks on when compiling itself. You really don't want to have to reformat a ton of working Gnat compiler source files.
I'd really like to see someone do this at some point, as it would make the checks much more useful to those of us who work for someone besides AdaCore.
In addition to trashgod's reference, I think Section 7.1 of this PDF might be of some help:
http://extranet.eu.adacore.com/articles/HighIntegrityAda.pdf
For reference, the existing GNAT style checking is described in the GNAT User's Guide under §3.2.5 Style Checking. As the rules are enforced by the compiler, additional rules would require corresponding modifications.