Wednesday 30 September 2015

How To Nest Selectors And Properties In Sass - Vanseo Design

How To Nest Selectors And Properties In Sass - Vanseo Design

How To Nest Selectors And Properties In Sass

Posted: 29 Sep 2015 05:30 AM PDT

Do you want to write CSS that's well organized, easier to read, and easier to maintain? Nesting is a feature of Sass that can help you keep related selectors and properties together to make your code more readable and maintainable.

Bird's Nest with Eggs

The last couple of weeks I offered an introduction to Sass. I talked about CSS preprocessors in general and walked you through some of the set up for installing Sass. I also showed you some code so you could see how to work with Sass. A few times I mentioned that we'd get to the more exciting features of the language in the coming weeks.

One of the first features of Sass you'll likely use is nesting. It's a natural first step into what Sass can do and while it may look a little odd at first, it won't take long to get used to.

However, not everyone agrees that you should nest your code. You can get carried away with nesting and cause more harm than good if you don't follow a few basic guidelines. Like most everything, there are pros and cons to nesting and I'll talk more about both next week.

Before we can understand the good and bad of nesting though, we should first talk about how it works.

Nesting Selectors

The easiest way to begin is with an example. With CSS it's common to chain selectors together as in the following example.

1  2  3  4  5  6  7  8  
footer {      background: #444;    }    footer p {      font-size: 0.875em;      line-height: 1.2;    }

This code sets a background color on the footer and then sets font-size and line-height for paragraphs specifically inside the footer. The footer p selector combines or chains two selectors together so the code inside the selector only applies to paragraphs inside footer elements.

Here's how you could do the same through nesting in Sass.

1  2  3  4  5  6  7  
footer {      background: #444;      p {        font-size: 0.875em;        line-height: 1.2;    }

Instead of writing the selector footer p, notice that the paragraph selector is written inside the brackets for the footer selector.

The nested code will compile to:

1  2  3  4  5  6  7  
footer {      background: #444;    }  footer p {      font-size: 0.875em;      line-height: 1.2;    }

Note: I'm using the :expanded output style, since it's the easiest to read. Your CSS output may look different if you're using a different output style.

The compiled code is the same as the CSS in the original example. Even with a different output style, the code is still functionally the same. The only difference is the whitespace that is or isn't used.

You aren't limited to two levels of nesting.

1  2  3  4  5  6  7  
footer {      p {        a {          color: #fff;        }    }    }

With this code you can see you're dealing with links inside paragraphs inside the footer. The Sass compiles to:

1  
footer p a {color: #fff;}

You may think the single line looks cleaner, but keep in mind this is a very simple example. I think nested Sass is easier to read as you add more code, though again not everyone agrees.

While you can technically nest selectors as many levels deeps as you want, you do have to be careful not to nest too deeply. If you do, you'll run into the same problems associated with chaining too many selectors together.

I try to limit nesting to two levels, though I will go three levels deep at times. Given the same HTML structure of a link inside a paragraph inside a footer, I would probably nest my Sass as follows.

1  2  3  4  5  6  7  8  9  10  11  12  13  
footer {      p {        styles here;      }      a {        styles here;        &:hover {          styles here;        }    }    }

Instead of nesting the link inside the paragraph I only nested the link inside the footer. The selector, footer a is less specific than footer p a. I reserved the the third level for the :hover pseudo selector.

Referencing Parent Selectors (&)

One of the things I often find myself doing with links is to remove the underline and then add it back on :hover.

1  2  3  4  5  6  7  
a {      text-decoration: none;    }    a:hover {      text-decoration: underline;    }

Sass uses the ampersand as a short cut to reference the parent selector.

1  2  3  4  5  6  7  
a {      text-decoration: none;      &:hover {        text-decoration: underline;      }  }

The ampersand will be replaced with the parent selector and the compiled code will look like the initial block of CSS.

It's not exactly a time saver in this particular example as & and a are both single characters, but the reference works with parent selectors that are longer than a single character.

You can also use the ampersand for more than pseudo elements like :hover. Here the ampersand is followed by the suffix -green

1  2  3  4  5  6  7  8  
.btn {      padding: 1em;      font-size: 1.2em;      &-green {        background: green;      }  }

which compiles to:

1  2  3  4  5  6  7  
.btn {      padding: 1em;      font-size: 1.2em;    }  .btn-green {      background: green;    }

If you use BEM or SMACSS when writing your CSS, you can probably see how referencing parent selectors like this can be useful.

If the parent selector can't have a suffix applied and still be valid CSS, Sass will throw an error. For example:

1  2  3  4  5  6  7  
:nth-child(5) {     color: #fff;     &-suffix {       color: #000;    }  }

Here the ampersand reference would lead to:

1  
:nth-child(5)-suffix

This isn't a valid selector so Sass will throw an error when compiling.

Trailing Parent Reference

The ampersand can also be used as a trailing parent reference. For example say you have the following HTML.

1  2  3  4  5  6  7  
<div class="one">      <p>Some text</p>    </div>    <div class="two">      <p>Some text</p>    </div>

Here we have two divs, each with a different class name. Both divs contain a paragraph with some text inside. Imagine that you want the text inside paragraphs to be black most of the time, but in the .two div you want it to be red.

You could reference the parent selector at the end of the selector as follows:

1  2  3  4  5  6  7  
p {      color: #000;      .two & {        color: #f00;      }  }

The Sass compiles to:

1  2  3  4  5  6  
p {     color: #000;    }  .two p {     color: #f00;    }

Your typical paragraphs would use black text, while the paragraphs inside .two will use red text.

Nesting Properties

In addition to nesting selectors, Sass lets you nest properties within the same name space. For example font-family, font-size, font-style, font-weight, font-variant are all in the same font namespace.

Instead of writing each property in full like this you can take advantage of property nesting in Sass.

1  2  3  4  5  6  7  
.headline {      font: {        family: georgia;        size: 2.4em;        weight: bold;      }  }

This compiles to:

1  2  3  4  5  
.headline {      font-family: georgia;      font-size: 2.4em;      font-weight: bold;    }

If you can write a property in shorthand, you can nest the properties in Sass.

1  2  3  4  5  6  7  8  
p {     padding: {       top: 1em;       right: 2em;       bottom: 3em;       left: 4em;     }  }

which compiles to:

1  2  3  4  5  6  
p {      padding-top: 1em;      padding-right: 2em;      padding-bottom: 3em;      padding-left: 4em;    }

You can also include one or more values on the property namespace. For example:

1  2  3  4  5  6  
.headline {      font: 2.4em/1.5 georgia {        style: italic;        weight: bold;      }  }

which compiles to:

1  2  3  4  5  
.headline {      font: 2.4em/1.5 georgia;        font-style: italic;        weight: bold;    }

I tend to use the shorthand as in padding: 1em 2em 3em 4em, but I think nesting properties like this is more readable.

Closing Thoughts

Nesting is one of the first features most people try when they started using Sass. I know it was the first feature of Sass I started using.

It took a little while for me to get used to nesting my code. Initially I wrote my code as though I wasn't using Sass and I had to remind myself I could nest it. Now I'll occasionally be working directly in a CSS file and have to remind myself that I can't nest code in the .css file.

You do want to be careful that you don't nest your code too many levels deep, but if you keep it to two or three levels you should be fine.

Nesting can fool you into thinking all your selectors are made up of single elements or classes when you've really chained a few together. This is one reason why you want to be careful not to nest too many levels deep, but let's leave that discussion for next week when we talk about the pros and cons of nesting.

Download a free sample from my book Design Fundamentals.

The post How To Nest Selectors And Properties In Sass appeared first on Vanseo Design.

This posting includes an audio/video/photo media file: Download Now

Wednesday 23 September 2015

Introduction to Sass — Part 2 - Vanseo Design

Introduction to Sass — Part 2 - Vanseo Design

Introduction to Sass — Part 2

Posted: 22 Sep 2015 05:30 AM PDT

If you've never worked with Sass or another CSS preprocessor before, you might be surprised how easy they are to use. It's as easy to get started writing Sass as writing the CSS you already know.

Sass Logo

Last week I mentioned you could start learning Sass by writing CSS in a .scss file. This week I'm going to show you. Then I want to talk about the different styles of output you can create when compiling Sass. I'll toss in a few words about adding comments to your Sass files.

Next week we'll begin to look at the features of Sass, starting with nesting, which is the first feature of Sass you're likely to use. I'll follow that up the week after with a look at Sass variables.

Using Sass

Sass code will naturally look a lot like CSS code. The easiest way to show you how to write Sass code is with a simple example. First here is a block of CSS code that might live in a file named style.css

1  2  3  4  5  6  7  8  
body {      background: #fefefe;    }    .container {      max-width: 80%;      margin: 0 auto;    }

Here's what it might look like as Sass in a file named style.scss

1  2  3  4  5  6  7  8  
body {      background: #fefefe;    }    .container {      max-width: 80%;      margin: 0 auto;    }

Can you spot the difference? It's a trick question as the code in both cases is exactly the same. The only difference is the name of the file.

You won't normally write your Sass exactly as you would write CSS, but I wanted to show you that making the jump to Sass is easier than you might think. If it's valid CSS it's also valid Sass.

Once you start working with Sass, you'll start to take advantage of more of its features and your code will look different. How different will depend on how many features of the language you decide to use.

I do want to make it clear that to start writing Sass is really as easy as writing the code you already write in a file with a different extension. From there you can begin to nest your code and use variables, which were the first two features I added, before adding more and more features that you find helpful.

The Original Sass Syntax

There are actually two different syntaxes you can use with Sass. The one I used above is the SCSS syntax, which requires you give your Sass files a .scss extension. This syntax looks like css, which is why I and many others choose to use it.

The original SASS syntax doesn't use the curly brackets or semi-colons. It relies on indenting and requires a .sass extension. My SCSS code above could be written in the original Sass syntax as:

1  2  3  4  5  6  
body      background: #fefefe    .container      max-width: 80%      margin: 0 aut

You can decide which you prefer. I like having the brackets and semicolons, because I find it easier to read and because it looks like the CSS I was already writing. However, there's nothing better or worse about either syntax. Choose whichever you prefer, but know I'll be using SCSS throughout this series.

Output Style

I mentioned above you can output your Sass in a few different ways. You have four options for how to compile your Sass code, each with it's own pros and cons. The four ways are:

  • :nested
  • :expanded
  • :compact
  • :compressed

Let's say you wrote the following precompiled Sass.

1  2  3  4  5  6  7  8  9  10  11  12  13  
.container {     color: #fff;     background: #363;    }    .container p {     width: 75%;    }    nav {     font-family: Georgia;     font-size: 0.875em;    }

You now have four choices for how the compiled code will be presented as CSS. Following are examples of each along with a brief definition of the output style.

:nested is the default Sass style and it will look like this when output. The only difference from the original is the curly braces have jumped up a line.

1  2  3  4  5  6  7  8  9  10  
.container {      color: #fff;      background: #363; }    .container p {      width: 75%; }    nav {      font-family: Georgia;      font-size: 0.875em; }

:expanded drops the closing curly brace back to its own line, which is probably a little easier to read. The curly braces are dropped to a new line, even if they had been included at the end of a line of CSS.

1  2  3  4  5  6  7  8  9  10  11  12  13  
.container {     color: #fff;     background: #363;    }    .container p {     width: 75%;    }    nav {     font-family: Georgia;     font-size: 0.875em;    }

:compact is like writing css selectors on a single line. Notice that the line breaks between selectors are preserved. If you prefer this style, you'll probably want to remove the extra lines between selectors in your Sass.

1  2  3  4  5  
.container { color: #fff; background: #363; }    .container p { width: 75%; }    nav { font-family: Georgia; font-size: 0.875em; }

:compressed strips out whitespace and minifies the resulting .css file. You won't find reading this output easy, but this is really what you should use for production code.

1  
.container{color:#fff;background:#363}.container p{width:75%;}nav{font-family:Georgia;font-size:0.875em;}

While developing, pick whichever of the first three outputs is easiest for you and then use :compressed when it's time to output for production.

Last week I mentioned you could use the following command to watch for changes to your .sass file and compile them into a .css file.

1  
Sass --watch style.scss:style.css

To control the output style you can add the –style flag to the end of the command.

1  2  3  4  
Sass --watch style.scss:style.css --style nested    Sass --watch style.scss:style.css --style expanded    Sass --watch style.scss:style.css --style compact    Sass --watch style.scss:style.css --style compressed

Hopefully I'm not doing too bad with the commands, given I rarely use the command line for anything.

Comments

It's good to comment your code to make it more readable for others and for yourself when you come back to a project after a few months away.

You can use both single line and multi-line comments in your Sass code

1  2  3  4  5  6  
// single line comment    /*  multi-line  comment  */

Multi-line comments will compile into the CSS file. They'll still be comments, but anyone viewing the CSS file will be able to see them.

If you want a comment to be in the Sass file, but not the CSS file use single line comments as they'll be removed during the compile.

Closing Thoughts

You might be wondering at this point, what the big deal is and why you'd want to use Sass since it probably seems like a more complicated way to write CSS. I promise there's more to Sass and I'll get to it starting next week.

Beginning to work with Sass is as easy as renaming your .css file to .scss or .sass and then writing CSS the way you always have or mostly the way you always have. You can compile your Sass code either through the command line or by using an app that will compile the code for you.

Once you have everything set up and get used to compiling the additional file, you can slowly integrate the features of Sass into your workflow.

When compiling your Sass, you'll probably want to use one of the the output styles that's easy to read until it's time to compile for production, at which point you should choose the :compressed output style.

I'll start to talk about the basic features of Sass next week when we look at nesting. The following week I'll talk about working with variables.

Download a free sample from my book Design Fundamentals.

The post Introduction to Sass — Part 2 appeared first on Vanseo Design.

This posting includes an audio/video/photo media file: Download Now

Wednesday 16 September 2015

Introduction to Sass — Part 1 - Vanseo Design

Introduction to Sass — Part 1 - Vanseo Design

Introduction to Sass — Part 1

Posted: 15 Sep 2015 05:30 AM PDT

CSS preprocessors have become part of many designer and developer workflows over the last few years as they help you write and maintain complex CSS code. They offer some of the features of programming languages when you want them, allowing you to ignore them when you don't.

Sass Logo

I realize there's a good chance you already use Sass or maybe Less or Stylus or some other CSS preprocessor that isn't familiar to me. I started using Sass about three years ago, though I hardly take advantage of all it can do. I have a feeling, I'm not the only one.

There are plenty of advanced topics I want to get into, but I don't want to leave anyone out (especially me) who doesn't have a good grasp of the basics yet. With that in mind I thought I'd start at the very beginning and assume you've never used Sass or any other CSS preprocessor.

If you already work with Sass, I'll do my best to uncover a few details you might not know and at some point this series should catch up with your knowledge and skills. With that out of the way, lets talk about what a preprocessor is and why you'd want to use one.

What is a CSS Preprocessor and Why Use One?

One of the original goals of CSS was that it would be easy to learn. To help with that goal the writers of CSS have generally shied away from adding features that might make the language more intimidating to learn, even if those features would be useful for more advanced CSS authors.

Enter preprocessors. CSS preprocessors are CSS-like languages with additional features. You write your code in the preprocessed language and you use whatever features you find helpful. When compiled your preprocessed code is converted into regular CSS that can be read by browsers.

One nice thing about Sass is the CSS code you currently write is valid Sass code. Once you have Sass installed and set up you can write CSS like you always do and pick and choose the additional features one at a time to incorporate into your code.

Some of those features and coincidentally some of what the posts in this series will eventually cover include:

  • Nesting — which makes your code easier to read and maintain.
  • Variables — so you can change a value once and have it update across the site.
  • Data Types and Operations — to do things like set the width of one column to always be half the width of another column.
  • @-Rules and Directives — for things like importing one Sass file into another and for extending the language.
  • Mixins to allow you to define styles that can be re-used throughout the stylesheet.
  • Control Directives — to add programming logic to your codebase.

There are also several libraries and frameworks available that make things like creating sprites or adding vendor prefixes easy and mostly pain free.

I have to admit when I first heard about Sass and other CSS preprocessors, I was skeptical. I was writing CSS fine and didn't think I needed to learn a new language to write what I already knew.

However, CSS stylesheets have become larger and more complex, even on smaller sites, and as they do the code become more difficult to maintain. The additional features Sass or any CSS preprocessor brings can help make your CSS easier to write and maintain. Sass allows you to write cleaner code that can do more.

Is Sass a Programming Language?

Because it adds some features common to programming languages you may wonder if Sass is a programming language. I'm probably not the best person to ask, since I'm not a programmer, but I'll do my best to answer.

It's certainly not a full fledged programming language though it does add features like variables and control directives (if, while, for) to CSS.

I think it's more properly classified as a scripting language. Sass adds logic to CSS and offers enough programming features for what we need it to do, but I don't think anyone would classify it as a programming language, which is good since that makes it easier to learn.

I guess you can call it a programming language for designers. It gives us the ability to add logic and control to CSS and offers some of the core concepts of programming languages without too much to overwhelm us.

And again the CSS you already write is valid Sass code (using the .scss syntax). You can start how I did and make use of nesting and variables, which are both easy to learn and from there make use of new features as you need or want. You're also welcome to ignore any feature you prefer not to use.

Basic installation and Syntax

Installing Sass is pretty easy. If I can do it, you can too. Sass is a Ruby Gem, which means you have to install Ruby first. If you're on a Mac, you're in luck. Ruby is already installed with OS X. Windows and Linux users will need to install Ruby first and then install Sass.

If you're running Windows you can download an installer here and if you're running Linux you can install Ruby in a variety of ways, depending on your needs and platform

Once Ruby is installed on your system open up the command line and run the following command to install Sass.

1  
gem install sass

or 

1  
sudo gem install sass

followed by you admin password in the latter case.

If you prefer to stay away from the command line entirely you can install one of several apps that will set up Sass for you. I use and recommend CodeKit, but there are other options both free and paid, which you can find on the install page on the Sass website. If you are a command line person you can type sass --help for the complete documentation.

Zell Liew recently published a good tutorial to help you get over your fears and allergies to the command line if you do want to give it a try.

For the rest of this series I'm going to assume you have Sass up and running whether that means using the command line or an app like CodeKit.

Compiling Sass

If, like me, you decide to use an app to handle everything, you'll want to check the documentation for the specific app to set things up to your liking. Odds are the default will be pretty good, but you can change a few things in how Sass outputs to CSS. I'll get to the different ways next week.

To work with Sass in CodeKit (which also compiles other languages by the way), I drag my project folder into it, which lets CodeKit know to keep an eye on that folder and update the CSS when I make changes to the Sass file. I'm guessing other apps will work similarly.

Before Sass I would set up a project file with an index.html (or .php) file and directories for my CSS and Javascript files, among others. Inside the css folder would be my style.css file.

Now, using Sass, I set up an additional scss folder that's a sibling to the css folder. Instead of writing in style.css, I create style.scss in the scss folder and let CodeKit, create and write to the style.css file when I make changes.

Alternatively if you want to use the command line you'll run

1  
sass style.scss style.css

to create the original css file and then

1  
sass --watch style.scss:style.css

to watch for changes to the .scss file and update the css file. You'll want to adjust the paths to the files (when using either app or command line) depending on your directory structure.

Again, if you do prefer the command line, I'll point you to a couple more articles from Zell about setting up projects using Gulp. He uses Sass as an example throughout both articles.

I'll pick things up from here next week.

Closing Thoughts

The main advantage to using any preprocessor is that you get more features to work with than are built in to the native language. The features allow you to write code that is easier to write as well as easier to maintain later.

Installation can be a scary word, but I promise installing Sass is easy and there are a number of tools that will do the work for you.

Next week I'll continue with introduction to Sass, hence the part 1 at the end of this post. I'll show you a quick example along with the different ways Sass can output CSS when compiling. In the weeks that follow, we'll get to some of the features that make Sass something you'll want to use.

Download a free sample from my book Design Fundamentals.

The post Introduction to Sass — Part 1 appeared first on Vanseo Design.

This posting includes an audio/video/photo media file: Download Now

Wednesday 9 September 2015

The Only Constant Is Change - Vanseo Design

The Only Constant Is Change - Vanseo Design

The Only Constant Is Change

Posted: 08 Sep 2015 05:30 AM PDT

Do you ever feel the need to make changes in your life and in your work so you can get to wherever it is you want to go? I know I do. Sometimes I even have the sense that I need to make major changes as opposed to minor ones.

Change can be difficult, but when I feel the need inside, I have to listen and I find it's best to make the changes no matter how large or how small. I took the last month away from writing for this site to listen to my inner needs and start implementing some changes I've known for awhile I should make.

Now that I'm back, I thought I'd give you a little more information about the time away along with some of the changes I've made and plan on making. I know I promised the start of a Sass series today, but I thought I should first offer more about why I took some time away. I'll start the series on Sass next week.

My Time Away

In my post announcing some time off I mentioned needing time for some personal and work related projects. I'll keep the personal projects personal and share a little about some of the work related projects that occupied my time.

One of the work related projects did involve this site. The site had been going down far too often and after several years, I didn't think that would change unless I moved to a new host.

In the process of moving the site I cleaned up a few things. I removed more than a third of the content that was here and I fixed a few things I'd been meaning to get to for months, if not years. Hopefully the site stays up more and works a little better now.

Another project involves my small business forum. For years, I've wondered what to do with it in terms of a business model. A few comments by a new member led to me think now was a good time and I started a conversation with a couple of friends about we could do with the site.

I'm not sure if the conversations will lead to anything, but we're talking regularly and I'm giving a few additional hours each week to the forum and the site we're going eventually create around it.

I'm Launching a New Site About Writing and Creativity

I've talked about transitioning from designer/developer to writer for a couple of years now and it makes sense for me to have a site dedicated to writing.

There are topics I often find myself wanting to write, but they don't belong on a design site and I end up not writing them. I want a place to publish some of the thoughts and stories I've been holding back for lack of a proper home.

I'm still in the planning stages for the site and I expect it'll be a few months time before I have the site live. For now I've set up a sign up form so you can be alerted when the site is ready.

I'll deliver a few extras to entice you to sign up, starting with a longer explanation for why I'm starting the site and what it will be about. I won't overwhelm you, but I'll probably send something once a month until the site is ready. In other words I'll be publishing articles via email for few months until the site is ready.

If you're here because you enjoy my writing or because you like the articles I write about creativity, productivity, and other non design and development topics, I think you'll like the new site I'm planning.

Again, it'll be a few months before the site is ready so sign up to know when it's live and for the few extras I'll deliver until that time.

What Do These Changes Mean for this Site?

As you might guess a new writing site and a potential site around my small business forum will require time and some of that time is going to come from the time I've been spending here.

Starting today I'll be publishing here once a week. I'm going to drop the Thursday podcast and post and move the Monday posts to Tuesday. The content I've been writing and recording for Thursdays will work better on the new writing site once that site is live.

As I mentioned, I've removed more than a third of the content that was here. It was mostly older posts that were about SEO and marketing. There was little traffic to any of them and they weren't relevant to a site about design and development.

I plan on removing more over the rest of the year and I want to reorganize what I decide to leave. My goal is to figure out the best way to make use of the content I ultimately decide to keep here on the site and to have the content be more focused on design and development.

Closing Thoughts

Sometimes I feel a strong need to make changes and in this case I needed some time away to process what I want to do and get started on some of the changes. I'm back after a month away and I'll continue writing design and development series, though do expect more changes to come.

This isn't the first time I've made significant changes to my work and personal life and I doubt it will be the last. This was one of those times where something inside was signaling I needed to make larger changes than usual and I've started the process with more changes to come.

Once again I want to remind you to sign up to be updated about the new writing site. If you enjoy my writing; if you enjoy the non design and development content I've published here, I think you'll like what I'm planning for the new site. More details when you sign up.

Next week I'll start the Sass series I promised for today. The series will start with the very basics and build up to more intermediate and advanced topics throughout the rest of the year and into next year.

Download a free sample from my book Design Fundamentals.

The post The Only Constant Is Change appeared first on Vanseo Design.

This posting includes an audio/video/photo media file: Download Now

Subscribe to: Posts (Atom)