.Less gets all Horn(get)y

Just a quick post to say that .Less/DotLess is now available via Horn and also via their web based package down loader.

My thoughts on using DotLess and the Less syntax

As some of you may know I have recently been hard at work porting Less Css for .NET and I thought it was about time I actually gave my opinion on the syntax and offered a few of my thoughts on usage.

Variables

The first thing that strikes most people about the Less syntax is the use of variables. I have to say I still find this extremely useful, and its often overlooked that properties and variables are also accessible from within a nested ruleset scope i.e:

#defaults {
  @width: 960px;
}
.article { color: #294366; }
.comment {
  width: #defaults[@width];
  color: .article['color'];
}

Also variables are, well.. erm…  variable and they change their value depending on the scope that you find them in i.e:

@var: red;
#page {
  @var: white;
  #header {
    color: @var; // white
  }
}

The use of variables really requires a little bit of thought. Other than the “corporate colour” example it is often difficult to determine what candidates are eligible for variables. I have found this is a lot easier if I’m working against a design and I site down with a cup of tea first and plan out my approach.

The other issue I have is that I can never remember the names of the damn things. This may be a personal problem with my goldfish like memory span, but I certainly wouldn’t sniff at a bit of tooling support. Now as I type we are currently looking at visual studio integration, but with true MS spirit, they have made this bloody painful so don’t expect instant results.

Mixins

Other than variables, which are pretty cool we also get the advantage of mix-ins and operators at our fingertips. Mix-ins are great for creating reusable chunks of style info that we can easily “mix-in” to another element.

That said, this same functionality can be gained by adding several classes to a HTML element. One of the first pain point I had with Less was trying to justify using mix-ins, and for the most part I have to admit they are pretty funky, but equally useless.

One pitfall, for example is that it is often it’s common to use client side scripting to effect page layout by dynamically adding or remove the CSS classes on an element. Obviously, this is not possible if we have mixed several classes into one instead of adding them separately to them HTML node.

HOWEVER…

As with anything, when used correctly mix-ins are really valuable. Where mix-ins really shine, is when you couple them with a framework such as blueprint, and if any of you have used such frameworks things like this won’t be uncommon:

class="span-15 prepend-1 colborder"

With mixins we can bundle all these together and make a single class i.e:

@import "~/Content/blueprint/screen.css";
#sidebar{
    .span-15;
    .prepend-1;
    .colbord
}

One, other cool thing worth noting about mix-ins is that you can access them via namespaces i.e:

.outer{
    content:"ignore me";
    .inner{
        content:"mix me";
    }
}
#mixer{
    .outer > .inner;
}

This obviously gives a much finer grain of control than simply adding CSS classes to an HTML element.

Its also worth mentioning that mix-ins also hurt my brain when trying to remember what I called the damn things. Once again, tooling will help here and I really should get on with the visual studio integration (or at least prod Erik a bit as he’s currently looking at it).

Imports

Imports allow you to bring together several Less/Css files and merge them into one. You will even be able to access variables/properties from the file you import. Imports are great even if you don’t want to use any of the syntactical sugar that you get with Less and simply want a way to merge your CSS files together.

All in all I can’t get enough of imports as a way of separating my Less style sheets into manageable, reusable sections. There are however, a few gotchas you’ll have to keep in mid with Imports, and they are:

• When caching is enabled in the Http Handler the cache will only be recycled if the main reference Less file is changed, and not any imported files.  This is no big deal, simply disable the HttpCache until you deploy.
• Imports will not have access to variables in the main reference Less file (or other referenced Less files in the main one). This ensures that imported Less files have no dependencies on where they are been used.

Futures

As with any language/framework/whatever there are issues that you will hit, but all-in-all I really enjoy working with Less. I think we could expand on the tooling though and as I mentioned our first port of call is VS integration, but other than this here are a few other ideas we have thrown around:

• Environmental and query string variables passed via the HttpHandler for use in our Less document.
• Conditional (IF/THEN/ELSE) blocks – This combined with environmental variables would allow switching on say browser or maybe the currently selected theme held in the session.
• Mix-ins with variables – this is actually implemented in the Ruby library, but we are yet to port it.

Any other thoughts and ideas welcome.

Advertisement

DotLess gets Twitter love – 1 hour in!

Today we launched a site to host dotless – less css for .NET and decided to tweet about it a little. Now the fact that I’m new to twitter and generally don’t have anything interesting to tweet about means I have about 3 followers. Some of the guys in and out of the dotless project however a slightly larger following, hence 1 hour in and we have had ~120 viewers.

nLess – Less Css For .NET

While the world ticks by and time to play with personal open source projects gets more and more limited it seemed like the best thing to do was to push live what I have with regards to my .NET version of  the Less library. With this in mind I have pushed my latest code up to codeplex at: http://nlesscss.codeplex.com/

When time permits(i.e. when I find a stable contract for a few months)  I’ll get back to working on the project, but until then enjoy the codeplex release.

EDIT: We now have a shiny new home for the .NET Less port – www.dotlesscss.com

Combining forces

After a few Skype chats with Erik we have decided to get out heads together and merge our LessCss .NET ports. This can only be a good thing and Im looking forward to see what the results are.

The tortoise and the hair

Today I learned that I was not the only one who though LessCss warrented porting to the .NET world, it appears that Erik van Brakel at smooth friction may have piped me to the post.  Looking at his project it seems I may be a few steps behind, though he also doesn’t have the Less spec tests passing.

So what do I do with this new information? Should I throw the towel in now? Well, maybe, but I have put too much time in to not finish my port, even if it ends up been more of a ill performant hack job than Erik achieves.  Time will see how it all plays out, but either way its been a great learning curve and Im glad there are people out there filling gaps who are happy to take on these types of projects.

Playing with PEGs

Im now part way through the Less CSS port and i am getting close to porting the core libary for programatically building the Less nodes that are evauated to create CSS. This now seems like a good time to look at the parsing element of the project.  Less originally uses a TreeTop as its parser libary, which I gather is a really powerful PEG/PackRat parser.  Now it should be said at this point that I know even less about parsing theory than I do about Ruby (why did I start this!).

My first steps here are to find out what the darn tootin’ a PEG parser is and see what C# had to offer. After a few hours hunting the bad news is that the .NET world has very little to compete with TreeTop although I did find a very detailed article about PEG parsers with a little implementation of one.  After downloading the code I can see that this is more than a “little implementation”, there has been a hell of a lot of work done on this project and it looks promising for a TT alternitive.

Ruby to C# (and probably not back again)

One day in the not too distant past I took on the unwise decision to attempt port a Ruby application to C#. The decision was unwise primarily due to the fact that I have probably wrote less than 20 lines of Ruby code in my life! But I wasn’t about to let a little thing like not understanding a programming language stop me, after all code is code!!

Now, I’m still currently about 3 weeks into this port (minus the time to fix hard drive failure) and I have to say I’m still quite a way from completing it. The application in question is Less, which is a great little parser that allows CSS type syntax with niceties such as variables, mixins and nested rules.

The source for Less is open source and freely avaliable from github, so there should be no problem porting it right? Well that’s what I thought too, but the interesting thing about Ruby is that it is a very free and dynamic language that allows the definition of what an object “is” to be determined at build and runtime. It does this through a variety of techniques the most impressive one is the use of mixins.

Mixins are a clever way to inject code from a module into a class without having to bring multiple inheritance to the table. This type of thing can only be achieved in C# with clever use of proxy classes, possibly using Castle Windsors IoC continer. Fortunately the structure of Less was such that I haven’t thus far had to go down this route, but it sure didn’t make it too much fun to understand what was going on intially.