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
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).
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.
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.
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.
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.
I wanted to thank you for this excellent read!! I surely enjoying every little bit of it I have you bookmarked to take a look at new stuff you post…