Although there are already other projects that wrap libsass, they don't appear to be maintained anymore, so I fork'd NSass and fixed some of the maintainability problems with it. From that, libsass-net was born.

Introduction

Recently there have been a few bugs that Sassy Studio users have been running into related to libsass that have been fixed for a while, but the wrapper I had been using (NSass) had not been updated in over 6 months. Since NSass was just a fork of libsass and then moved the files, getting the updates from libsass would not be an easy process.

To solve this issue, I created a new project on GitHub and brought in the code using a git submodule which should allow me to very easily grab updates as the roll out and become stable.

Roadmap

Currently, I’m a bit bogged down with a new job and a basement project so right now libsass-net is the bare minimum amount of work that I needed to do to get it working for Sassy Studio. In the somewhat near future I plan on adding support for the following (pull requests welcome):

  • NuGet packages
  • x64 support (currently it works, must a manual process)
  • ASP.NET handler
  • System.Web.Optimization integration
It's that time of the year again when we look back and reflect on what we accomplished during the previous year and set goals for the next year. Here are the highlights from my 2013.

2013 shaped up to be an amazing year. I started blogging again and was able to write about 18 blog posts which is pretty good for not blogging in years. I learned quite a bit of basic German using Memrise and Duolingo while running on the treadmill during my lunch break. I also went through a lot of interviews, some that turned out really well, others that didn’t turn out so great.

In the development realm, I learned about Sass and began to use it in production. I made Sassy Studio, my first Visual Studio extension that helped me out with all the work I was doing with Sass. At the time of writing, Sassy Studio has been downloaded over 4,300 times!

I also made murmurhash-net which helped me overcome some performance and storage problems we hit with SHA1. This also happens to be my first NuGet package, which was fun to do as well.

On the non-technical side, I read all of the Ender’s Game series and started the Ender’s Shadow series. I also started reviewing an upcoming technical book about Visual Studio 2013.

A new year and a new job

After 8 years, I’ll be leaving my post as lead developer at hh2 and moving on to DevResults. It’s kind of crazy to be moving into a different industry, but I’m really excited about the new tasks that await me and I’m looking forward to seeing what impact I can make in the international development and humanitarian communities.

I’m also excited about keeping focussed on Sassy Studio both on resolving issues and adding new features. Hopefully I’ll be able to refactor major portions of the SassyStudio code into a full-blown Sass compiler.

On the side of things I’m not looking forward to, but definitely am going to get accomplished, this year will be the year that I get my dog new hips to fix her hip displaysia which will hopefully let her live a pain free rest of her life.

Goodbye 2013, hello 2014

As with everything, I hope this year we can all live in the present but be mindful of all the things we learned in 2013. Happy new years everyone!

It’s been a little while since the last blog talking about what’s new in SassyStudio there has been a lot of new features.

Nested Property Intellisense

The major new feature in v0.8 is smarter css property intellisense for nested properties. Consider the following style, you will now get intellisense suggesting values like family and weight when in the font block.

body {
	font: {
		size: 14px;
	}
}

Format Document support

There is some basic support for automatically formatting a document. Right now, it only supports fixing indentation issues, and the indentation options are configurable in the same place as all other languages (Tools > Options > Text Languages > SCSS). Thanks to @Unt1tled for requesting this.

Compilation of file when dependent document changed

Now when you modify a document that is imported by another root level document, the root document will be generated. This was a long overdue feature and I’d like to thank @funzeye for requesting it.

Basic Compass Support

If you are a compass user, you’ll be glad to know that SassyStudio now bootstraps compass and will use it to generate your css files when you save them. All you need to do to enable support for compass is to provide the path to your ruby installation path in the options (Tools > Options > SassyStudio > Ruby Install Path). Thanks to @okoetter for requesting this.

Various Intellisense / Parsing Improvements

As usual there have been some various bug fixes.

  • Fix CSS intellisense not working when only VS2013 installed
  • Fix @if directive not parsing correctly when immediately followed by (
  • Improve CSS property detection and fix properties declarations not followed by a space not being highlighted correctly
  • Fix incorrect highlighting after using comment/uncomment selection command

Moving Forward

As usual, I’ll keep enhancing the existing functionality and work on adding more intellisense support. I’ll continue tweaking intellisense to get it to the point where I feel comfortable enough enabling it by default. If you find anything broken or confusing, please feel free to reach out to me on Twitter or file an issue on GitHub.

The first SassyStudio specific feature is support for the functionality to get intellisense in other files without the using the @import directive.

Update: Looks like the LESS functionality in visual studio supports the same syntax as this, which is awesome! Originally I was using the attribute file but have since updated it to use the attribute path to match.

With large applications you’ll typically find yourself breaking your SCSS files into logical groups, typically centered around functional components. This is clean and efficient, but you lose intellisense when you do… until now.

To accomplish this, I have started support for the reference tag in a triple slash (///) comment. An example of this would be

/// <reference path="variables" /> 

To get intellisense for multiple files, just add multiple references

/// <reference path="variables" />
/// <reference path="mixins" />

The reference tag works the same as a @import statement, and it can serve as documentation for what files the current file you are working on depends on.

If you have any other ideas for what you would like to see supported in SassyStudio, please feel free to submit a feature request on GitHub

In my recent work in SassyStudio to support the SCSS language I have hit a few hurdles. While I don't have any problems with the SCSS specification, I think it's worth delving into some tooling hurdles that I've encountered due to the way SCSS works.

Back To Basics - CSS

First, lets disect a very basic CSS rule set

ul li:hover {
    color:red;
}

Here we have a few components.

  • ul and li:hover are the "selectors" for this rule.
  • :hover is a pseudo-selector for the li element that only applies when the element is being hovered over
  • color:red is setting the color property of the li element's foreground text to red

Pretty simple. The CSS syntax is pretty flat compared to SCSS which adds nesting, so it means that the selectors will always be at the root of the document and then the rule body will have properties. It is also worth noting that CSS does not require there to be any whitespace between the colon and the property value.

Now lets look at an equivalent SCSS rule set

ul {
    li:hover {
        color: red;
    }
}

Since SCSS allows us to have nested selectors, we bump into our first problem: pseudo-selectors. Let's say you have typed out your ul rule set and begin typing li and then hit the colon. Currently, we are in an ambiguous context: do we have an li element that we would like to show code completion for pseudo-selectors or do we have a li property?

There's a few ways to resolve this, but they are all brittle: we could try to see if we have a valid property name, but that requires us to keep an up-to-date schema, including browser specific properties, which is ideal, but tough. Furthermore, we could have non-text property names and selector components like #{$some-variable} which would then require us to evaluate the variable, which could be expensive.

Another way we could address this problem is look at the element and see if there is a pseudo-selector for it. Unfortunately this won't work because most pseudo-elements apply to all elements.

The most logical way to address this problem (although still not useful in the code completion context) would be to look for the opening curly brace to determine if something is a selector or not. Unfortunately for us, SCSS supports nested properties which means that the following is a completely valid property, not a selector.

.nesting {
    font: 2px/3px {
        family: fantasy;
        size: 30em;
        weight: bold;
    }
}

Granted in that example there is a space after the colon, but the example doesn't matter as much as the concept. There's no real definitive way to know definitively tell between a property and selector when there is only one value, and thus, the only safe way to handle this scenario from tooling is by not providing completion for pseudo-selectors, only properties.

This is still not ideal, but it's better than the alternative, which would be that anytime you entered the property value context by typing a colon, you would get a list of pseudo-selectors, pseudo-classes, and pseudo-functions. Since you are likely to be providing more properties than selectors in a document, I chose to err on the side of assuming something is a property.

Reflecting back

When it all comes down to it, the main problem here is that the SCSS language (which is a superset of CSS3) introduces some ambiguities that were not present in CSS3. While they are fairly easy to work around at a document level, they aren't as easy to work around in an interactive environment.

How would I solve this? Unfortunately, I don't have any great ideas yet. Ultimately, if there was an operator for nested selector like the parent reference operator, this wouldn't be a problem. We would have an easy way to tell the context we were in and it would make parsing a lot simipler. On the other hand, it's not really necessary and would likely get annoying. Ultimately the problem arises only when you are in the process of writing your document; everything is simpler when dealing with the document as a whole. Unfortunately, that's almost the entire process from the tooling aspect.