d e v o n
Andulka
#extradirty
Claire Keane
Discoholic 🪩
tumblr dot com
Janaina Medeiros
Show & Tell
"I'm Dorothy Gale from Kansas"
RMH
Today's Document
Kiana Khansmith
ojovivo
Lint Roller? I Barely Know Her
Jules of Nature
Kaledo Art
oozey mess
Monterey Bay Aquarium
No title available
KIROKAZE
seen from United States
seen from Morocco
seen from Israel
seen from United Kingdom
seen from Italy
seen from Morocco
seen from United States
seen from United States
seen from United States
seen from United States
seen from United States
seen from United States
seen from United States
seen from United States
seen from United States
seen from United States
seen from United States
seen from India
seen from United States
seen from United States
@dmitnate-blog
What is Sass?
In short, Sass extends CSS to make it feel more like a scripting language than a stylesheet.
Sass (Syntactically Awesome Style Sheets) is a popular CSS extension language, allowing for the implementation of powerful features such as variables, nesting, mixins, and inheritance. Sass also allows for easy modularization through partials and imports. Finally, Sass provides operators to allow for helpful math to be done directly in your stylesheets.
What is CodeKit?
CodeKit is an application for OS X (Windows users can use Prepros as an alternative) that handles preprocessing, error checking, and cache management for web projects. We will be using CodeKit to preprocess our Sass files, and turn them into a single minified CSS stylesheet that can be included in our project.
You can purchase CodeKit here.
Project Setup: Sass Directory
Typical project directory has a “styles” folder, which contains two child folders. One for development (Sass), and one for distribution (CSS). The Sass folder will never interact with any project files, and does not technically need to be included in the final project directory at all. However, it is good practice to include your Sass, should another developer need to revise the project in the future.
Since we will be modularizing our Sass, we will have additional child folders in our Sass directory. The organization and naming of these folders depends on the project, and is ultimately up to the developer (that’s you).
For the purposes of this tutorial, we will be using the structure outlined by The Sass Way in their How to Structure a Sass Project resource. This setup uses three main folders: Modules, Partials, and Vendor.
The Modules folder is where we will place our variables, mixins, and other Sass which doesn’t output any real CSS to our distribution folder.
The Partials folder is where we put the actual styles that will be converted to CSS during preprocessing. This includes things like typography, forms, headers, widgets, et cetera.
The Vendor folder is somewhat self-explanatory. Place any third-party stylesheets here. You can use Sassmeister to convert third party CSS to Sass.
Along with the module folders, the Sass directory should also have a single Sass file. This will be the file that will include all of our modules, and can be named something along the lines of main.sass or styles.sass.
Project Setup: CodeKit
Launch CodeKit and select File, New Project. Select the main project directory, not just the styles folder.
Once the project has loaded, you can select the gear icon at the top left to adjust how our Sass will be compiled. Select “Sass” from the Languages section of the sidebar.
The Sass configuration page has two sections: Settings and Output Paths. Settings is not terribly important, and relies on your personal preference for how the final CSS should look. Output Paths, however, is an important part of the project setup process.
To start compiling Sass, make sure “Generate output files for this language” is enabled. Select “To this folder” as the output path, and assign it the value “../dist”.
You can modify the name of the outputted file, but for this tutorial we will be using the wildcard (*.css) to have CodeKit simply copy the name of the original Sass file.
Basic Sass Syntax
Let’s dive into the syntax. Sass is written similarly to CSS, except we remove the brackets and semi-colons. Sass is extra picky about spacing, make sure to pick a tabbing method and stick with it. Using the tab key is recommended. It’s a lot harder to accidentally hit tab twice than it is to hit the space bar one too many times and not notice.
Modularizing Your Sass
Modularization can be done by using Sass partials and imports. A module/partial file is declared by placing an underscore before the filename. i.e. “_myStyles.sass”.
Import a partial Sass file into a document by using @import “path/file”. The file name does not require the underscore or .sass suffix to be defined.
All of your Sass files, aside from the main styles.sass file, should be partials. Then, all partial files can be compiled into the styles.sass file using  @import.
Sass Variables
Variables can be declared with the following syntax: $foo: bar
Any time $foo is used, the value of bar will be printed in its place. Variables are a great way to maintain global constants, such as colours or size values.
It is important to remember that variables use the same cascading behaviour as typical CSS. The variable value must be declared before it can be used.
Sass Nesting
Nesting is a great way to organize your Sass. See the example below of the Sass intuitive visual hierarchy in action.
Sass Mix-ins
Mix-ins add even more module-style behaviour to our stylesheets. By declaring a Sass mix-in, we can set a group of attributes that can be included elsewhere in our Sass. When the mix-in is modified, so are all references to it. Similar to variables, make sure to declare mix-ins before using.