16 June 2009 5:35p Pacific

Imagine CSS evolved as a programming language

by Matt Sherman

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

Comments

17 June 2009 6:35a Pacific #

Sean Carpenter
Why does it need to be ported?  I installed it with "igem install less" and it works for me (at least using a simple less file).

Sean Carpenter United States |

17 June 2009 9:36a Pacific #

Matt Sherman
Well maybe port isn't the word. Knowing nothing about IronRuby or the DLR, I am hoping to have it in the form of a dll or class library or VS project. Would like to see it implemented as an HttpHandler to remove the need for pre-processing -- just deploy .less files directly.

Matt Sherman United States |

18 June 2009 12:12p Pacific #

Brian McNitt
Interesting idea. Two issues. Designers, the primary users off CSS, don't think like coders. Coders understand variables, code reuse, nested code structures, and think DRY. Coders enjoy tight order -- that's how they work best. As an example, you probably have less than 20 icons organized in a grid pattern on your desktop. But look at a designers workstation and desktop -- hundreds of icons, piles of books, and sticky notes everywhere. It's a completely different mind and way of approaching problems. Also, the nested syntax works well for external stylesheets but starts to become pretty designer-unfriendly in inline CSS (i.e. - style ="p { span { a:link,a:visited { text-decoration: none; } } }"). I get it but I don't think you could impose this level of structure on the average designer. Thinking they would work better with current CSS syntax, even if less efficient. It would however be nice if both syntaxes were available and you could declare which you are using. Of course, having two syntaxes would get messy too. Mostly think this will appeal to coders working in the UI world. ;)

Brian McNitt United States |

18 June 2009 1:28p Pacific #

Matt Sherman
I certainly come to it from a programmers angle, no question.

But perhaps we are giving the current CSS too much credit. There is nothing designer-friendly about the existing syntax IMHO. It's just that designers are accustomed to it.

Matt Sherman United States |

18 June 2009 1:45p Pacific #

Ian Patrick Hughes
I started to pattern my CSS design approach based upon the popular frameworks (personally, I liked Blueprint best). While your suggestion above *would be* the best approach, it just isn't in the specification so we're screwed.

But, you can think of CSS Id's as Singleton concrete classes in the OOP world. One instance that is globally accessible and uses CSS classes as almost kind of like inherited interfaces when decorating an element.

I like the idea of LESS, in theory. The same way I like other language compilers that port into other languages. These seemed to have become more and more popular in recent days too as the need for client-side coding and making everything "ajaxy" has become required for most web applications. The same back-end programmers that have been bemoaning IDE's and managed languages as being dangerous levels of abstractions seem to have no issues asking for something that ports JAVA to JavaScript all of a sudden.

Personally, I think embracing the title of polyglot programmer is always a good idea. The past year I have been trying to stay out of the SQL world as much as possible with LinqToSQL and Entity Framework. However, try as I might, I keep discovering scenarios where crafting a good sproc and even deploying an SSIS package offer better flexibility down the line and performance right away.



Ian Patrick Hughes United States |

Comments are closed

Tell others

TwitterTweet this page
Digg!Digg this page
TwitterAdd to Google Reader

Experimental! Let me know how it works for you.

Shorten this page's URL

Learn more about the TinyASP URL shortener

ASP.Net jQuery Controls

Implement jQuery effects using familiar ASP.Net server controls. Learn more...

Recent posts

Alikewise learnings #1: DIY PR

Sherman’s law of prior knowledge, or, predicting the past

The busiest people at Apple right now…

When “infographics” jump the shark

HTTPS is the least of your problems

Stacking up

Beware the truth-tellers

Please don’t write “efficient” CSS

more...  

About us

ClipperHouse.com is brought to you by Matt Sherman and Fernando Chilvarguer, among others. Contact us here.