New terms from treehouse – Sass Basics Part 1 – Getting Started with Sass and Variables, Mixins, and Extending Selectors

Getting Started with Sass

What is Sass?

Sass is a CSS language. CSS is a subset of Sass, which means that by writing CSS you’re already writing valid Sass. It just extends CSS. Sass is not an acronym, but there is one for it (syntactically awesome stylesheets).

A compiler works by taking an input and turning it into an output. Browsers understand CSS, but not Sass. So, Sass gets compiled into CSS. Sass is for developers, and CSS is for the browsers.

---

Installing and Using Sass

Sass was built with ruby, so you need it to install it if you’re on Windows or Linux. Mac comes with ruby by default, so just open the command line and write gem install sass. The user I was signed in as didn’t have permission to do that, so I had to sudo before it.

To check if it installed and to see what version you have, enter sass –version.

We’ll then start by making our first empty test Sass file, which ends in .scss. Then, in the console we write sass, then the file name.

It gave us nothing, because there was nothing in the file. So, let’s add some stuff to the file and rerun it.

 

If you don’t feel comfortable with the command line, the scout app will take care of this for you.

Working with this long term, we want to enter sass –watch ., which will actually create a CSS file for you, and update it every time you update and save your .scss file. So, it compiles Sass while you work.

There are different ways to install depending on the language you’re using. There are two versions of Sass, one is LibSass, a more portable version, and the original.

---

Nesting Selectors

We have a sample site and have set up our scss and css files, using the sass –watch . command from before.

Let’s say we set up some styles using a class and descendent combinator.

If the class name were to change, we’d have to go and change each style that had that class name, which could take a while on a huge site.

With Sass, you can write nested styles, and the compiler will still write valid CSS for you!  This makes it easy to add new styles for a specific point. This is based off the concept DRY (don’t repeat yourself).

Try not to overdo it with nesting. Only go 4 of 5 levels deep at most. Going deeper usually implies you need more classes and id’s in your markup.

Modernizr is a JS library that works well with Sass, which we’ll add to the page.

Modernizr adds a bunch of classes to your html tag, which allows you to dynamically determine what the browser can and cannot do. This is useful because it lets you write CSS based off that feature.

Here, if the browser supports css columns, this CSS will be applied and overwrite rules written above it.

---

Advanced Nesting

The parent selector feature is represented by an ampersand (&). Below, in the Sass we’ve added a rule with html.csscolumns & as the selector. As you can see in the CSS, this means that what’s written before the &, in this case html.csscolumns, will be put ahead of the other selectors, .blog .entry p, which are represented by the &, in the css. So, we end up with html.csscolumns blog .entry p

Now let’s say another h1 was added and we wanted to style just that.

As you can see, it affects all h1’s on the page, and we don’t want that. Normally we’d fix this by using the direct child combinator >. This is supported by sass as well.

You could clean it up further by combing the nesting with the styles below.

The & works with hover states and such as well. Think how much easier this is than having to write out a:hover, a:visited, a:link, etc.

Finally, by default Sass simulates nesting by indenting parts of you CSS, to give you an idea of how the original Sass looked.

---

Variables, Mixins, and Extending Selectors

Defining Variables

You’ll often use a color multiple times in a project. If you wanted to change it, you’d have to change it in all those locations you used it.

With Sass you can define variables and use them throughout your CSS. They must start with a dollar sign.

Here we have a site already put together with Sass, with some repeating colors.

To set up variables, write their name, then a colon, then the value, then a semicolon. Then, all you need to do is use that variable name when you need that value. Here, we’ve set up #333 as $primary_color.

This makes it easy to change this color later.  You can change it in one place, the variable declaration, rather than having to change it each place you need it.

You can do this for margins as well, pretty much whatever you want. Notice how easy it makes it to change the styles.

You can actually take a variable and multiply its value, like they did for padding here. In this case the padding is now 7.5px.

You can also do just normal inline calculations without a variable. It accepts division, subtraction and addition as well.

We can make variables this way as well. Since we’re using pt units, it will convert them to px for you in the css.

If you try using ems though, you’ll get an message telling you where the error is.

---

Introducing Mixins

Here we have some code that’s getting repeated quite a bit for the border radii.

To add a mixin, start with @mixin, then the name of the mixin, then curly brackets, in which you put the code you want.

Then, to use a mixin, in the css rule write @include, then the name of the mixin you want to use, then end it with a semicolon like any other css declaration.

The final product:

You can even set up mixins with selectors. Note how Sass auto scoped it so that the a is nested within the .box class for us.

---

The Power of Mixins

You can pass arguments into mixins like you would a JS function. You do this by putting parentheses after the name of the mixin when declaring it, then popping in your arguments. So, now whenever this is included, roundy is expecting these two numbers (for #radius-one and #radius-two).

Since in this example radius-two seems to just be the double of radius-one, we can dry things up even further and only use one argument with a calculation.

Note that it the arguments you pass in don’t have to be just numbers, you can use other things like colors too.

Here’re the golden rules for mixins. Also, this color choice looks more pee than gold to me : O

---

Extending Selectors

Let’s say you need to copy some code, like for .bar here, to a new class called menu. In CSS you’d copy and paste like this.

Or, you could use a mixin like last lesson. But extend is a great directive to solve the same problem. You simply type @extend, then the name of the selector you want to extend, in this case .bar. You can see that in the CSS it basically merged the selectors together.

Issue that came up when they developed this: People wanted to use more semantic classes like .menu and .nav, based off of .bar, but they ended up with .bar appearing in their css without actually using it. So, they came up with placeholder selectors, which are represented by a % then a name.

Now, bar is a placeholder selector and doesn’t get printed to our css. The rule of thumb for using mixins vs extends is that mixins are great for arguments and advanced logic, like building a library, while extends are for smaller scale, simpler things where you just want to copy some stuff with no arguments or logic.

New terms from treehouse – Git Basics Part 2 – Merging, Working with Remote Repositories, and Workflowst

Merging

Intro to Merging

This how you get your branches back together, it’s like the opposite of branching. It merges all of the branches’ changes and commits into one cohesive timeline. The other branch doesn’t go away, and you can keep merging and working on it as long as you like, you’re just copying the commits from one branch into another.

If a file was changed in both branches, this is called a merge conflict and you need to decide which one to keep. Git does its best to auto resolve these for you, and if it can’t it will ask you.

Basic Merging

If you don’t have conflicting changes between two branches, merging can be done easily. Let’s merge foo_feature back into master. Start with git branch to see where you are, and make sure you’re in master. Then, use the git merge command followed by the name of the branch you want to merge into the one you’re in now.

Let’s set up some merge conflicts by changing the README in our two branches.

Since they were on different lines, git auto merged them for us. Both commits are now listed in master. It does this by creating a new automatic merge commit.

Remember that the foo_feature branch is still around, and that the merge only affected the master branch.

---

Merge Conflicts

Here, git will present you with the conflict and ask how you want to handle it. We’ll set one up by making changes to the same line in file1.

When we go to merge, we get this conflict message.

To resolve this, you can just edit the conflicted file so it matches. If we open file1 in our text editor we’ll see conflict markers which show us where the conflict occurred. The angle brackets surround the conflict, and the equals signs separate the two versions.

You can just remove the conflict markers and save that if you want, delete the change from one of the branches, or combine them, which I’ve chosen.

Now, we need to add our commit to the staging area, then run git commit.

Git knows we’re correcting a conflict, and has created a useful commit message for us.

---

Working with Remote Repositories

Working with Remotes

If someone needs to work on a project with you, they can’t use your repository because it’s on your computer. But, they can make a copy of yours for their computer, and this is called cloning.  Later, after you’ve both worked on it for a while, you can merge your copies of the repository, much like you would merge branches. You’d have a central repository on a server somewhere that is the official version of the code.

---

Cloning

In this example, we’re going to clone a repository on our computer, but cloning a remote one would work the same way. You can clone a repository using the git clone command, followed by what to clone. You can optionally add what you’d like it to be named after that.

If we look inside our new directory, we’ll see it’s a copy of our files, and we can access the git log just like before.

Git also automatically set up our original repository, named origin, as a remote one when it set up this new one. The git remote command lets us see all the remotes available to this repository. In this case, there’s just the one called origin.

If go to our original repository and run the git remote command, nothing gets printed out, which means the original repository isn’t affected at all by the clone. This is good, because if a lot of people were making copies, you wouldn’t want to have have it affect the original every time.

Still to get the origin to notice and be able to talk with the remote one, use the git remote add command. Note that you can choose a name for it, in this case “our_clone”.

---

Pushing and Pulling

We’ll start by creating a new branch in our cloned repository, then changing file2’s text and committing it.

To get this back to the remote repository, we can push our change using the git push command, which should send all of our changes to there.

It says everything is up to date, which seems like nothing happened. This is because the new_feature branch we created doesn’t exist in the remote repository yet. Git doesn’t know it needs to be tracking changing in that branch across both repositories. You need to explicitly say that by adding it to the git push command.

Once again an issue. By default, the first argument you provide git push needs to be the remote. Otherwise, it will assume you’re referring to git origin. Seems we need to explicitly state that here.

If we switch back to our origin repository and check it’s branches, we can see it’s now there. If we were to check its git log, we’ll see the commit for file2 there as well.

Let’s say the person working on the origin didn’t like the change to file2 in the new_feature branch and wants to edit it. They do that, then switch back tot he master branch.

Meanwhile, the other dev is working in their clone project repository, and edits file2 again. We’ll then push the change to the remote.

But, we get an error saying that our file is not up to date, so we can’t push. We can update our end with the git pull command. It takes two arguments, the remote to pull from, and what branch. It tries to pull it over and gets a merge conflict error.

Pull works like merge, the difference being instead of pulling in changes from another branch, it grabs them from another repository. Time to resolve the conflict by editing the file2 with nano, and picking what we want to keep.

We save, add our file to the staging area, and then commit it. We confirm our git message, the try git push again.

Back in the master, we’ll make an edit to file1 and commit it, then try running git push.

We get an error about no configured push destination, so let’s add that.

---

Workflows

Git-Flow

Git-flow is a sub command you can install for git. Once installed, we’ll add a new branch, then initialize it using the git flow init command, which will ask you a series of questions about your preferred workflow. First you choose what will be your production branch. In this case we’ll choose master, which is the usual choice.

Next it asks you to set the branch for integration of the next release, where features will go when they’re finished, but before they go live on the site. This is what we created the integration branch for.

Next it asks you about branch prefixes. Git-flow’s model is to handle everything by creating a branch, which can be overwhelming if you’re not careful with the organization of them. These prefixes help to categorize the branches.

Next it asks you about the version tag prefix. Git allows you to add tags for your commits. Anytime you move a change to the master branch, git-flow will tag it with a special message so you can find it later.

The initialization process is done, and now you can use git-flow. To start a new feature, enter git flow feature start, then the features name. You’ll see it tells you the branch was added with feature/ before it, in the integration branch. It also tells you what to do when you’re done.

When you’re done, it will merge the branch into the one specified and switch you to it (integration in this case), as well as delete the branch you were working on.

To make a hotfix, it works the same way, only you use the command git flow hotfix start, then its name. Note that it’s based off the master branch this time, because it’s a hotfix.

When you’re done, finish it the same way as before.

Git-flow will prompt you for a tag message, save, and you’re good to go.