Telerik RadControls for ASP.NET are getting a bit Sassy

Spoiler: yes, we'll be using Sass…

Writing CSS tends to be mundane for the most part of it. Yes, it has truly exciting moments in a twisted kind of way, but for the majority of the time it's the same thing line after line, after line, after line…

I really hate it when front end developers can't be lazy when it comes to writing CSS. I mean the rest of the developers had all kind of goodies to help them write less — be it helpers, code generators, frameworks… Developers of other language had it relatively easy when compared to CSS coders, who had to write everything by hand.

Usually at some point one would code a small CSS parser to facilitate the process of writing CSS, perhaps by replacing variables, but overall the problem of writing little CSS and getting more of it was not properly solved.

Or at least the problem wasn't solved until a couple of years ago when CSS pre-processors and meta languages came into the scene and writing CSS became somewhat bearable.

For those not familiar with CSS pre-processors (or CSS meta languages), it's a language that at the end of the day complies (interprets actually) to pure CSS. Such language would have selector nesting, variables, arithmetic, functions, includes and that kind of features.

Currently, there are two popular frameworks slash pre-processors: Sass and Less, with both being somewhat similar and yet different. How the two languages differ is not what this blog post is about, but if you care enough to know, you can either Google, or check this Sass vs. Less comparison table.

Some of you might be aware that KendoUI is using Less for its stylesheets. However, for the RadControls for ASP.NET Ajax, we decided to go with Sass, because it fit the needs for that project better.

What does Sass look like?

In a nutshell, SCSS looks a lot like CSS. For a longer explanation, here is quote from the Sass website:

Sass has two syntaxes. The new main syntax (as of Sass 3) is known as “SCSS” (for “Sassy CSS”), and is a superset of CSS3's syntax. This means that every valid CSS3 style sheet is valid SCSS as well. SCSS files use the extension .scss.
The second, older syntax is known as the indented syntax (or just “Sass”). Inspired by Haml's terseness, it's intended for people who prefer conciseness over similarity to CSS. Instead of brackets and semicolons, it uses the indentation of lines to specify blocks. Although no longer the primary syntax, the indented syntax will continue to be supported. Files in the indented syntax use the extension .sass.

If you find the above a bit gibberish, stay tuned it will all be clear in a couple of lines…

Features of Sass

I did mention this briefly, but Sass offers very neat features and adds new on a regular basis. The most prominent features are: selector nesting, variables, mixins, functions, inheritance.

Nesting

That's one Sass features we use a lot: every selector you nest within another selector will result in a rule that combines both selectors exactly as you imagined it.

The example bellow shows how we are using the nesting, by not having to write the parent selector (in this case .RadAutoCompleteBox) for each sub rule. Note that the visual indenting is not required by SCSS, we are using it for better code readability:

Includes and mixins

Sass allows for styles to be written in separate files and included when needed. It also allows for portions of code do be defined as mixins and be used at a later point.

The example shows how to define and use a mixin. We are using this trough out the RadControls styles by defining common parts for reusing. Mixins can also take parameters which makes them even more flexible. Imagine writing cross-browser border-radius with a single line! (Of course that line will be compiled to multiple lines.)

Variables

Sass supports variables too. They are defined like a style property, only preceded by a dollar sign. In addition, variables can be interpolated and included as strings:

By using variables we ensure that all the values that need to be the same are the same; another added benefit is the reducing of typos i.e. if a variable is miss-typed in Sass, the compiler will throw an error and we'll fix it.

There are of course much more features of Sass, but those are just the basics. if you haven't seen Sass yet, you should really browse the Sass site for a detailed look of its features.

Benefits

The first time we used Sass was when we created the MetroTouch skin. It was from upmost importance that the colours be the same and all images are contained in a single file. By using Sass variables and mixins we were able to do this in much shorter time than it would have taken otherwise.

Ideally, once we are done with the skin conversion, both in terms of syntax and proper variable usage, new skins will be made in fraction of the time it used to take: it will require a new common skin file, which contains all the color variables and skin name; a new sprite, which we are looking for a way to automate; and that's it.

Downsides

The biggest downside so far was compile time. Written originally ruby and only in ruby so far, Sass compiles as fast as the ruby interpreter runs. On windows ruby is notoriously slow. I mean really slow…

We had the idea of styles to be written only in Sass and then compiled upon build, but that didn't turn out well as it increased the build time so we dropped that option. The only other option was to compile it locally and ship the generated CSS.

That presented yet another show stopper — how to compile it? I am fine with using the ruby gem with a —watch directive, but not all front ends are comfortable with the console. Thankfully, there is this really nice Visual Studio extension called Web Workbench by MindScape that allows for scss to be written and compiled directly in Visual Studio. It even groups the Sass and CSS files as a parent / child item in the solution explorer.

Bottom line

Bottom line is that I am happy as hell that we are using a pre-processor to offload some of the mundane CSS related task. The variables are helping us to slowly but surely unify the look of the controls; we are using mixins to work around browser specific styles; the output option takes care of the minifying thing…

What's next?

Apart from getting most controls converted to using Sass, we are looking for a way to make the Visual Style Builder use the Sass files. By using variable names it should be much easier to customize the skins...

Be on the lookout for more Sass related posts, as we'll try to cover some basics and more advanced topics, as well as hints about what is and where in the skins solution.