I’ve gotten reasonably good with CSS, but I often find myself feeling that certain concepts are conflated or a bit ad hoc.

CSS does two separate things:

• Defines a set of visual attributes as a “style”
• Specifies the DOM elements to which those styles are to be applied

These are different ideas, IMHO. For example, I’d like to define a color palette in once place, and then apply it in different ways throughout in my style library.

What if I want to apply a primary brand color to my links and also to the background of my header? I need to specify it in two places – and then track down all those places if the palette changes. Ditto if I decide that my standard margin needs to go from 10 to 15.

There are ways of doing reuse and encapsulation in regular CSS, but they are not intuitive. Do my DOM elements inherit styles from their parents? Do styles inherit attributes from one another? It seems like I need to implement the logic anew for each case – violating DRY. And the “logic” is spread across CSS and the DOM.

So I’m intrigued by this thing called LESS. It’s a CSS “compiler” that allows you to express your styles with things like variables and hierarchy, in a quasi-CSS syntax. Then it converts that syntax to real CSS for the browser. For example:

@brand_color: #4D926F;

#header {
  color: @brand_color;
}

h2 {
  color: @brand_color;
}

That’s very readable to me and the reuse is obvious. How about this:

#header {
  color: red;
  a {
    font-weight: bold;
    text-decoration: none;
  }
}

That looks a lot like inheritance. It’s terse and intuitive.

LESS is written in Ruby and it requires you to pre-process your CSS before you deploy. So…who’s gonna port it to .Net (IronRuby?) and turn it into a HttpHandler?

:)

--

PS: this sort of thing could greatly simplify skinning, too

...is someone I hadn't heard of until I read this very amusing post: Ruby on Rails and the importance of being stupid. The comments are every bit as interesting as the article.

I like his economic thinking too, with obligatory reference to the excellent The Forgotten Man, which I am now "reading" (ie, glancing at, half-finished, on my desk).

I was a physics major, not a computer science guy. Turns out physics is great training for the problem-solving that programmers do. I was surprised by what Philip had to say about computer science, not least that most CS graduates are not good programmers and that MIT apparently doesn't offer a course on databases?

Having not taken CS, I've wondered what they teach. Is it low-level how-does-RAM-work type stuff? Because most of the practicable skills I see in programmers come from experience, even if they have the degree. Seems to me a person with a technical mind, motivation, and a grounding in math could become a very good programmer in about two focused years.

To be a great programmer, s/he would also have to be a linguist. :)