When is a sass required

Also, Sass has a much sharper attention to detail than other preprocessors. As far as I can tell, the core designers care deeply about supporting every corner-case of CSS compatibility and making sure every general behavior is consistent. In other words, Sass is a software aimed at solving actual issues; helping to provide useful functionality to CSS where CSS falls short.

Preprocessors aside, we should also mention tools like PostCSS and cssnext which have received significant exposure these last few months. It parses every rule to see if vendor prefixes are needed by referencing the browser support tool CanIUse and then removes and adds vendor prefixes that are needed. You have to know a bit of JavaScript to build anything with it, and its API can be confusing at times.

In short, Sass is somewhat easy and will solve most of your problems. Thanks to Cory Simmons for his help and expertise on this section. A styleguide is not just a pleasing document to read, picturing an ideal state for your code. It may look like overkill for small projects, but it helps a lot in keeping the codebase clean, scalable and easily maintainable. Needless to say, the more developers involved on a project, the more code guidelines are needed.

Along the same lines, the bigger the project, the more a styleguide is a must. First things first: this is not a CSS styleguide. These guidelines only aim at dealing with Sass-specific content. Also, this styleguide is my own and therefore very opinionated. Think of it as a collection of methodologies and advice that I have polished and given over the years. It also gives me the opportunity to link to a handful of insightful resources, so be sure to check the further readings.

Obviously, this is certainly not the only way of doing things, and it may or may not suit your project. Feel free to pick from it and adapt it to your needs. As we say, your mileage may vary. At the end of the day, if there is one thing I would like you to get from this whole styleguide, it is that Sass should be kept as simple as it can be. Thanks to my silly experiments like bitwise operators , iterators and generators and a JSON parser in Sass, we are all well aware of what one can do with this preprocessor.

Meanwhile, CSS is a simple language. Also, and let me quote Harry Roberts once again, pragmatism trumps perfection. At some point, you will probably find yourself going against the rules described here. If it makes sense, if it feels right, do it. Code is just a means, not an end. A large part of this styleguide is strongly opinionated. I have been reading and writing Sass for several years now, to the point where I now have a lot of principles when it comes to writing clean stylesheets.

I understand that it might not please nor suit everybody, and this is perfectly normal. Although, I believe that guidelines are made to be extended. Extending Sass Guidelines could be as simple as having a document stating that the code is following the guidelines from this styleguide except for a few things; in which case, specific rules would be explained below.

An example of styleguide extension can be found on the SassDoc repository :. Anything from this document overrides what could be said in the Node Styleguide. If you ask me, the very first thing a styleguide should do is describe the way we want our code to look. When several developers are involved in writing CSS on the same project s , it is only a matter of time before one of them starts doing things their own way. Code guidelines that promote consistency not only prevent this, but also help when it comes to reading and updating the code.

Roughly, we want shamelessly inspired by CSS Guidelines :. Believe it or not, strings play quite a large role in both CSS and Sass ecosystems. Most CSS values are either lengths or identifiers, so it actually is quite crucial to stick to some guidelines when dealing with strings in Sass. To avoid any potential issue with character encoding, it is highly recommended to force UTF-8 encoding in the main stylesheet using the charset directive. Make sure it is the very first element of the stylesheet and there is no character of any kind before it.

CSS does not require strings to be quoted, not even those containing spaces. Because of this, Sass also does not require strings to be quoted. That being said, languages that do not require strings to be quoted are definitely a minority and so, strings should always be wrapped with single quotes ' in Sass single being easier to type than double on qwerty keyboards.

As per the CSS specifications, the charset directive should be declared in double quotes to be considered valid. However, Sass takes care of this when compiling to CSS so the authoring has no impact on the final result.

You can safely stick to single quotes, even for charset. Specific CSS values identifiers such as initial or sans-serif require not to be quoted. Indeed, the declaration font-family: 'sans-serif' will silently fail because CSS is expecting an identifier, not a quoted string.

Because of this, we do not quote those values. Hence, we can make a distinction between strings intended to be used as CSS values CSS identifiers like in the previous example, and strings when sticking to the Sass data type, for instance map keys.

If a string contains one or several single quotes, one might consider wrapping the string with double quotes " instead, in order to avoid escaping characters within the string. In Sass, number is a data type including everything from unitless numbers to lengths, durations, frequencies, angles and so on. This allows calculations to be run on such measures. Numbers should display leading zeros before a decimal value less than one.

Never display trailing zeros. In Sublime Text and other editors providing a regular-expression powered search and replace, it is very easy to add a leading zero to most if not all float numbers.

Do not forget the space before the 0 though. When dealing with lengths, a 0 value should never ever have a unit. Beware, this practice should be limited to lengths only. Having a unitless zero for a time property such as transition-delay is not allowed.

Theoretically, if a unitless zero is specified for a duration, the declaration is deemed invalid and should be discarded. Not all browsers are that strict, but some are. Long story short: only omit the unit for lengths. The most common mistake I can think of regarding numbers in Sass, is thinking that units are just some strings that can be safely appended to a number.

While that sounds true, it is certainly not how units work. Think of units as algebraic symbols. For instance, in the real world, multiplying 5 inches by 5 inches gives you 25 square inches. The same logic applies to Sass. Note that adding 0 member of that unit also works, but I would rather recommend the aforementioned method since adding 0 unit can be a bit confusing. Indeed, when trying to convert a number to another compatible unit, adding 0 will not do the trick.

More on that in this article. In the end, it really depends on what you are trying to achieve. Just keep in mind that adding the unit as a string is not a good way to proceed. Appending a unit as a string to a number results in a string, preventing any additional operation on the value. Slicing the numeric part of a number with a unit also results in a string. This is not what you want. Use lengths, not strings. Top-level numeric calculations should always be wrapped in parentheses. Not only does this requirement dramatically improve readability, it also prevents some edge cases by forcing Sass to evaluate the contents of the parentheses.

Needless to say magic numbers are a plague and should be avoided at all costs. When you cannot manage to find a reasonable explanation for why a number works, add an extensive comment explaining how you got there and why you think it works. Colors occupy an important place in the CSS language. Naturally, Sass ends up being a valuable ally when it comes to manipulating colors, mostly by providing a handful of powerful functions.

Sass is so useful when it comes to manipulating colors that articles have flourished all over the internet about this very topic. May I recommend a few reads:. In order to make colors as simple as they can be, my advice would be to respect the following order of preference for color formats:. CSS color keywords should not be used, unless for rapid prototyping. Indeed, they are English words and some of them do a pretty bad job at describing the color they represent, especially for non-native speakers.

On top of that, keywords are not perfectly semantic; for instance grey is actually darker than darkgrey , and the confusion between grey and gray can lead to inconsistent usages of this color. The HSL representation is not only the easiest one for the human brain to comprehend [citation needed] , it also makes it easy for stylesheet authors to tweak the color by adjusting the hue, saturation and lightness individually. RGB still has the benefit of showing right away if the color is more of a blue, a green or a red.

Therefore it might be better than HSL in some situations, especially when describing a pure red, green or blue. Although it does not make it easy to build a color from the three parts.

Lastly, hexadecimal is close to indecipherable for the human mind. Use it only as a last resort if you have to. When using HSL or RGB notation, always add a single space after a comma , and no space between parentheses , and content. When using a color more than once, store it in a variable with a meaningful name representing the color. Now you are free to use this variable wherever you want.

However, if your usage is strongly tied to a theme, I would advise against using the variable as is. Instead, store it in another variable with a name explaining how it should be used. This article does a good job at explaining why thinking your color variables through is important. Both lighten and darken functions manipulate the lightness of a color in the HSL space by adding to or subtracting from the lightness in the HSL space.

The thing is, those functions often do not provide the expected result. On the other hand, the mix function is a nice way to lighten or darken a color by mixing it with either white or black.

The benefit of using mix rather than one of the two aforementioned functions is that it will progressively go to black or white as you decrease the proportion of the color, whereas darken and lighten will quickly blow out a color all the way to black or white.

The scale-color function is designed to scale properties more fluidly by taking into account how high or low they already are. Lists are the Sass equivalent of arrays. A list is a flat data structure unlike maps intended to store values of any type including lists, leading to nested lists. When adding new items to a list, always use the provided API. Do not attempt to add new items manually. In this article , I go through a lot of tricks and tips to handle and manipulate lists correctly in Sass.

With Sass, stylesheet authors can define maps — the Sass term for associative arrays, hashes or even JavaScript objects.

A map is a data structure associating keys to values. Both keys and values can be of any data type, including maps although I would not recommend using complex data types as map keys, if only for the sake of sanity. Write-ups about Sass maps are many given how longed-for this feature was. At this point, this is mostly revising what everybody knows, but here is how a CSS ruleset should be written at least, according to most guidelines, including CSS Guidelines :. I cannot think of many topics where opinions are as divided as they are regarding declaration sorting in CSS.

Concretely, there are two factions here:. There are pros and cons for both ways. On one hand, alphabetical order is universal at least for languages using the latin alphabet so there is no argument about sorting one property before another. However, it seems extremely weird to me to see properties such as bottom and top not right next to each other. Why should animations appear before the display type? There are a lot of oddities with alphabetical ordering. On the other hand, ordering properties by type makes perfect sense.

Every font-related declarations are gathered, top and bottom are reunited and reading a ruleset kind of feels like reading a short story. But unless you stick to some conventions like Idiomatic CSS , there is a lot of room for interpretation in this way of doing things. Where would white-space go: font or display? Where does overflow belong exactly? What is the property order within a group it could be alphabetical, oh the irony?

There is also another interesting subtree of type ordering called Concentric CSS , that seems to be quite popular as well. Basically, Concentric CSS relies on the box-model to define an order: starts outside, moves inward. I must say I cannot decide myself. Because of this, I will not impose a choice in this styleguide. Pick the one you prefer, as long as you are consistent throughout your stylesheets i.

A recent study shows that using CSS Comb which uses type ordering for sorting CSS declarations ends up shortening the average file size under Gzip compression by 2.

One particular feature Sass provides that is being overly misused by many developers is selector nesting. Selector nesting offers a way for stylesheet authors to compute long selectors by nesting shorter selectors within each others. Along the same lines, since Sass 3. For instance:. This method is often used along with BEM naming conventions to generate. The problem with selector nesting is that it ultimately makes code more difficult to read.

One has to mentally compute the resulting selector out of the indentation levels; it is not always quite obvious what the CSS will end up being. To prevent such situations, we talked a lot about the Inception rule a few years back. It advised against nesting more than 3 levels deep, as a reference to the movie Inception from Christopher Nolan.

I would be more drastic and recommend to avoid selector nesting as much as possible. For starters, it is allowed and even recommended to nest pseudo-classes and pseudo-elements within the initial selector. Using selector nesting for pseudo-classes and pseudo-elements not only makes sense because it deals with closely related selectors , it also helps keep everything about a component at the same place.

Also, when using component-agnostic state classes such as. Last but not least, when styling an element because it happens to be contained within another specific element, it is also fine to use nesting to keep everything about the component at the same place. In order to ensure consistency, a significant change affecting the acquisition is one that meets any of the following criteria:.

Not included in the definition of services in 10 U. Included in the definition of services in 10 U. COCOs should participate in all other strategy meetings with the decision authority when the clearance approval authority is below the SCO.

This is a U. Configuring modules with use If you find yourself wanting to configure many variables at once, pass maps as configuration, or update the configuration after the module is loaded, consider writing a mixin to set your variables instead and another mixin to inject your styles.

To ensure that stylesheets work on every operating system, Sass loads files by URL , not by file path. This means you need to use forward slashes, not backslashes, even on Windows.

All Sass implementations allow users to provide load paths : paths on the filesystem that Sass will look in when locating modules. Modules will always be loaded relative to the current file first, though. Relative imports are always available. These are called partials , and they tell Sass tools not to try to compile those files on their own.

In addition to loading.