Notes on dotLess

Tuesday, March 02, 2010 11:49 AM

I’ve been working on a restructuring of this blog and decided it was about time I entered the modern age.  I’ve always pretty much developed CSS by hand in Notepad.  This is, to say the least, a frustrating and time-consuming experience.  Now I’d heard of dotLess from Daniel Hölbling’s blog and thought it was time to give it a go.  (As an aside, I know that dotLess is a ruby port.  Many of these issues may well also apply to the original codebase.)

In summary, dotLess is good and I’m enjoying using it, but it could be great.  Let’s start with usability.  If you fail to terminate a variable, it doesn’t tell you.  It simply keeps going until it finds an appropriate termination.  No warning that you’re generating a variable name with >8000 characters and multiple newlines in its name or value.  It has issues with unterminated CSS directives as well.

Then there’s what happens if you refer to a mixin or variable with the wrong name.  It crashes, which isn’t too bad.  However, it doesn’t tell you what name it couldn’t find or where in the file it was processing when it failed.  Again, this just makes more work for the user, and wouldn’t be very hard to fix.  It’s also a pity the --watch command line parameter wasn’t working in the version I downloaded.

Current Selectors Nested Rules

I’ll admit, I wish I’d thought of the whole nested rules concept.  It’s simple, it’s powerful and it encourages good CSS design.  However, I can’t help feeling the whole thing could be even more powerful.

In particular, nested rules currently only handle elements within the declaring element.  Wouldn’t it be great if we could say the following easily?

  • The text for this element is red, including any links in the text.
  • The left margin on a UL is 0px, except in IE7 where it needs to be 8px.
  • The post’s heading should be red, unless it’s within a digest where it should be blue.

Basically, if we could have a syntax for “current selector”, we’d be able to do really cool things and make the dotLess files even smaller and more readable.  Here’s a proposal: have ampersand (“&”) represent the current selector in a nested rule.  You can keep the existing syntax as well: there’s no conflict between the two.  But now you can say things like this:

.redText { 
    &, & a, & a:hover { color : red; }
}

UL {
    margin-left : 0px;
    *:first-child+html & { margin-left : 8px }
}

.post h1 {
    color : red;
    .digest & { color : blue; }
}

This isn't my idea, it's already fully implemented in sass and less.js.  It's an awful lot simpler than turning dotLess into progamming language, and solves most of the problems that people trying to solve by introducing programming language features.  This is part of a much longer rant: JavaScript already exists, Modernizr already exists.  dotLess is a useful tool, but duplicating functionality is going to be a waste of time.

CSS3 Problems

Using modern features and, in particular, unadopted features causes a few problems.  There’s two main issues here: if you define multiple values for a property, it just uses the last one.*  This is fine, except that web designers sometimes do this in the knowledge that different browsers will read different lines.

For instance,

h1 {
    background: -moz-linear-gradient(top, @primary, @primaryDark);
    background: -webkit-gradient(linear, left top, left bottom, from(@primary), to(@primaryDark));
}

Will generate a file containing only the webkit specific instruction.  Historically, that hasn’t been such an issue, but it’s becoming one at the moment.  Also, there’s another reason this code doesn’t work: dotLess variables don’t like being in a larger CSS expression, so in practice this code doesn’t even work for webkit browsers.

Use it

All in all, I’m going to continue to use it.  The operations stuff is incredible: I can actually do things like say “It needs to be the colour which at 80% opacity will merge with the background to make navy blue.”  Expressing stuff like the holy grail layout is relatively easy as well (never thought I’d say that, it’s normally a complete pain). 

*All of this was from the 1.0 beta download in January.  I’m not the first to spot this issue and for all I know it’s already fixed in source.

Technorati Tags: ,
Comments
Gravatar
# re: Notes on dotLess
Posted by Daniel Hölbling on 3/2/2010 6:47 PM
Hi,
sorry for the problems you have been experiencing with dotless. We are still trying hard to work out most of the problems. James just re-implemented the whole treebuilder class to provide us with a more robust parsing structure.

I will look into the --watch feature shortly. I tried the latest build today with --watch and it didn't work either (no clue why, it worked perfectly when I implemented it a few weeks back).

As for multiple instructions getting kicked to the curb, that change should go up tomorrow that removes the declaration merging, so two background: declarations will not get mushed into one any more (killed some of my sticky footer scripts).

As for the error reporting: That has been our problem since day one and we are planning to fix this shortly. Getting the treebuilder there is one of the main steps since the original code did not really have any logging in it. The new infrastructure should be in place in <2 weeks to provide better error messages on parsing problems.

greetings Daniel
Gravatar
# re: Notes on dotLess
Posted by Daniel Hölbling on 3/3/2010 12:21 PM
Hi, I just wanted to let you know that the --watch parameter now works properly. Was a stupid mistake at passing the filter parameter into the FileSystemWatcher.

greetings Daniel
Something to add?

Talking sense? Talking rubbish? Something I'm missing? Let me know!

Fields denoted with a "*" are required.

 (will not be displayed)

 
Please add 1 and 5 and type the answer here:

Preview Your Comment