SCSS vs LESS. Part: 2 Nesting

SCSS vs LESS. Part: 2

Nested Rules

Nesting CSS rules can be handy in any web implementation. Rather than having many long CSS definitions you can simply use nested rules. This allows for visually clear inheritance in your code.

However, used incorrectly will see your compiled CSS have large chunks of over qualified CSS selectors in turn bloating your CSS by sizeable amounts and slowing down your website. eg.

.boom .bing .bam{
  a{
    color: hsl(0, 100%, 50%);
  }
  #unique{
    color: hsl(0, 50%, 50%);
  }
}

Above I require the ID #unique to be referenced in this section of CSS. This markup may look neat. However once compiled It will look like this:

.boom .bing .bam a {
  color: #ff0000;
}
.boom .bing .bam #unique {
  color: #bf4040;
}

As you can see the second rule is over qualified. The ID being unique can be used by itself. A bit of trap for preprocessor rookies. Also problematic to fix in large SCSS/LESS files.

Both SCSS and LESS have a very similar syntax for nesting. For chaining selectors use an ampersand. eg.

 // SCSS/LESS  .boom input{
 color: black;
 &[type="password"]{
   border: dotted red 1px;
 }
 &.large{
   padding: 10px;
 }
 &:hover{
   background: red;
 }
}

Will output as:

.boom input {
   color: black;
 }
 .boom input[type="password"] {
   border: dotted red 1px;
 }
 .boom input.large {
   padding: 10px;
 }
 .boom input:hover {
   background: red;
 }

SCSS allows you to use an ampersand to reference the nested parent anywhere in the nested selector. Where LESS only supports this as a first character as defined in the previous example.

//SCSS Only
a {
 color: red;
 &:hover{
   text-decoration: underline;
 }
 body.ie6 & {
   color: green;
 }
}

This will allow you to reference Modernizr tags or Browser conditional Classes.

a {
 color: red;
 }
 a:hover {
   text-decoration: underline;
 }
 body.ie6 a {
   color: green;
}

Nested Properties

SCSS has a feature that is not supported by LESS and that is nested CSS properties. I’m a fan of shorthand properties. However this is a neat feature to have in the toolkit.

// SCSS
a:hover {
 transition:{
   property: font-size;
   duration: 4s;
   delay: 2s;
 }
 font-size: 36px;
}

This allows you to nest any property with a dash (according to the documentation). The complied code is below:

a:hover {
 transition-property: font-size;
 transition-duration: 4s;
 transition-delay: 2s;
 font-size: 36px;
}

Conclusion

SCSS and LESS are almost identical in nesting their selectors. Apart from SCSS’s extra functionally with referencing the parent selector they are almost identical. That said, SCSS is much better at nesting with the added functionality of property nesting. SCSS is everything LESS is plus more. Winner: SASS (SCSS).

SCSS vs LESS. Part: 1

So I have been using LESS and SASS recently and I decided to write up a comprehensive post on them both. I will be gradually doing this as the languages are both very large.

SASS

SASS (Syntactically Awesome Stylesheets) appeared on the scene in 2007. First sporting a syntax that had very different markup from CSS (.SASS), It later released SCSS which is based on CSS markup. It is now a solid platform that is used widely among web developers. It’s latest release was two months ago (Version 3.2.3 – November 9, 2012).

LESS

LESS released it’s first iteration of it’s CSS preprocessor in 2009. It was heavily influenced by SASS (and still is. SCSS was also influenced by LESS). It’s syntax tries to be as close to CSS as possible. LESS also is wildly used.

Documentation

The documentation on the LESS site is limited to one single very long page. To be honest, it’s shit. They seriously could have done a better job. In actual fact the entire LESS website is one page. If they want developers to take up their language give them a decent book to read. SASS on the other hand is no better. Again single page documentation. However it looks like they are starting to separate this as some documentation is on it’s own page. Apart from that they really need to setup a decent documentation site.

Variables

Variables are very similar in both languages apart from how you define them. SASS uses a Dollar sign($var) where LESS uses an ampersand (@var) they can be defined and used like below:

// SASS (SCSS)
$myWidth: 5em;

#main {
  width: $myWidth;
}
// LESS
@myWidth: 5em;

#main {
  width: @myWidth;
}

The variables in both cases handle the following types of values:

Numbers

eg: 0, 0.1, 10px, 0.5em. (One thing to note, both languages round up negative values like .5em to a 0.5em). You can also do maths when defining your varible:

@test: 10 / (2 * 50) - 0.1;

Strings

e.g. "Boom"'Whoop', dang

Colours

When you define colors like red or blue LESS converts these to HEX values where SASS treats these as strings and leaves them alone.

It’s nice that LESS is trying to be smart and all but I think when I define my colours as words I don’t want anything to change. Eg: if I define Blue or Teal it is for a reason.

What No HSL! That’s right. When Defining HSL colours both convert these to HEX values. Also when define HSLa value these get converted to RGBa. What. The. Fuck! (also: http://mothereffinghsl.com/)

// SASS and LESS [SCSS markup]
$myHSL: hsl(1, 100%, 50%);
$myHSLA: hsla(1, 100%, 50%, 0.5); 
.red{
  color:$myHSL;
  background: $myHSLA;
}

// output
.red {
  color: #ff0400;
  background: rgba(255, 4, 0, 0.5);
}

Booleans

eg: true, false

nulls

(e.g. null)

Order of definition

One thing i noticed with LESS, when defining a variable twice or thrice it always uses the last definition inside that rule regardless of when it may be used, eg:

.main{
 @myVar: 100px;
 width:@myVar;
 @myVar: 2em;
 height: @myVar;
}

would output to:

.main { width: 2em; height: 2em; }

Weird, A bug maybe?. SASS outputs the following:

.main {
  width: 100px;
  height: 2em;
}

Comma Separated Lists

eg: (item1, item2, item3)

Example:

.main{
 $myFontStack: arial, helvetica, sans-serif;
 font:12px $myFontStack;
}

Conclusion

I think they are so close I would not choose either based on these findings. If anything i’m leaning towards SASS because of the order of definition bug? It’s just weird. You would think they would follow how other main languages work.

Apart from that LESS and SASS both convert HSL and HSLa colours. It would be nice if neither tinkered with how I define my colours. If I want to set HSLA colours, LET ME SET HSLA COLOURS. Comprende? And don’t mess with the W3C pre defined colours! I use “Tan”, “Peru” and “Tomato” in all my websites!

Adam out!

SCSS vs LESS. Part: 2 Nesting

The Breakpoint Ep. 4 —The Tour De Timeline

The DevTools’ Timeline shows the heartbeat and health of your application’s performance. In this episode we’ll do a deep deep dive into how to uncover the cost of internal browser operations like parsing HTML, decoding images, invalidating layout geometry and painting to screen. Paul and Addy will show you how best to approach improving the performance of your CSS and JS.

The Breakpoint Ep 3: The Sourcemap Spectacular with Paul Irish and Addy Osmani

Take Coffeescript to Javascript to Minified and all the way back with source maps. In addition to a new Coffeescript sourcemap workflow, we’ll cover the latest sourcemap updates so you can understand how to dramatically improve your debugging experience. Finally, Paul and Addy will be joined by special guest—Yeoman core contributor Sindre Sorhus—to discuss what big new changes are coming to the project.

Chrome Developer Tools: Sources Panel

You may have noticed a new panel appear in the Chrome Developer Tools. The sources panel was recently added to the already powerful web development tool. The sources provides you with the source code of your website. It allows you to edit your website on the fly.

One of the main features includes the ability to save revisions of your source code allowing you to track your changes and revert to a previous version of a source file. When you edit your source simply pressing ‘Ctrl + S’ will create a revision. You can then right click the file you just saved on the left hand sources panel and click ‘Local modifications’ to see your revisions. You will see all your saved revisions with timestamps and revert links.

Another nice feature is the ability to save an edited source file locally to your hard drive. This pretty much opens Google Chrome as a stand alone web development tool.

While in the sources panel if you press ‘Ctrl + F’ you will see a standard find tool with Find and Replace functionality. Which is nice to have.

A nice new tool is the ‘Pretty Print’ button (The two curly brackets button) which basically converts your minified source code to readable and editable code.

There are many more features in the sources panel that I have not covered. I think for any web developer this is a must ’Try out’ feature.

Why every web developer should join the Mozilla Developer Network (MDN)

Documentation is essential for learning web developers. Most new developers pop over to sitepoint or buy a book from O’Reilly. But I’m offering another option. Some new developers even head over to w3schools.com thinking its affiliated with the w3c, which it’s not (check out http://w3fools.com/). Either way there are many libraries on-line however none are really affiliated with a major body. Except MDN.

The Mozilla Developer Network (MDN) is an excellent source for budding web developers. It covers all of the main areas for web development including one of the best JavaScript guides on-line. Being affiliated with Mozilla, the creator of Firefox means they will always be focused on the web.

So why should I join the MDN? Well one of the great things about the MDN reference site is that it’s an editable Wiki. Meaning you can add to the documentation, you can contribute to the learning of new web developers. The slogan that sits at the top of the home page “It’s the Web. You drive.” sums it up nicely. I signed up and within minutes I had the power to edit any documentation on the site.

So sign up, contribute, spread the word and let us make this the authority source for learning.