Comments on: Write Better CSS with Less

By: AussieJohn

AussieJohn — Sun, 05 Jul 2009 23:30:29 +0000

@BerislavLopac: Don't forget that it's not always practical to add classes to elements, not to mention that it certainly isn't semantic in a lot of cases. With, as you suggested - a different syntax to indicate that a class is a mixin (something like %mixinClassname or +mixinClassname perhaps?). I think this could be a very successful feature of CSS. @YahyaAziz Don't leave out the nested rules :-)

#banner { 
2	  color: white; 
3	  background: black; 
4	    a { color: yellow; } 
5	    p { margin: 0em; } 
6	    ... 
7	}

By: BerislavLopac

BerislavLopac — Sun, 05 Jul 2009 21:39:13 +0000

@YahyaAziz: The last item is completely unnecessary, as it can already be easily done as .footer.super.

By: YahyaAziz

YahyaAziz — Sun, 05 Jul 2009 20:17:05 +0000

Raena, thanks for an interesting (and obviously provocative!) article.

I agree with Molte, who said: “And when you say variable, don’t you mean constant?”

I also agree with Arlen – right up to the point when she or he (rather contentiously) implies that designers don’t get the reusability of heritable class attributes. I think that any designer worth her salt understands the principles of modularity and of design integrity very well indeed.

Why not campaign for the kinds of simple improvements to CSS that would make all these preprocessor-type tools unnecessary? It wouldn’t take much:

1. Include named constants eg:
@logo-color = #abcdef;

and invoke them with:
color: @logo-color;

2. Allow run-time arithmetic on constants, eg:
@base = 960px;

invoked with:
width: @base / 3;

3. Allow class inheritance, as per Less’ mixin in Raena’s example:
#super {
#footer;
font-family: cursive;
}

Designers, just as much as programmers, would welcome the chance to (a) defer and (b) readily change, the decisions they take. We all know that most design changes are customer-driven, and adding flexibility to respond quicker to customer requests makes everyone look good.

We’re not talking an insurmountable extra run-time load involved in these kinds of changes (unless used to baroque excess).

Just my 5c. worth (Anyone seen two cents lately?)

By: Arlen

Arlen — Thu, 02 Jul 2009 14:00:29 +0000

@cloudhead OK, so your “mixins” are simply another way of doing what we’ve been able to do for years without ever involving the CSS file in the first place, namely assigning a class to an element that has another class or id already assigned to it?

I’m afraid the clarification doesn’t change my assessment of it. There’s still no way to tell from looking at it whether this is a class that was written for the purpose of styling an element, or a class/mixin/codechunk that was written solely for the purpose of being included in other ids/classes. And it still means that cleaning up after a development sprint will still require looking for that class/mixin/codechunk will require looking in not only the content files, but the less/css files for where it’s used.

@raena, What I meant was that, like using the same variable name over and over, the Less mixin syntax leaves you no way to write it without having to leave commentary or other documentation behind to explain what you’re doing (”class A is a real class, but class B here is a fake class that only exists because I want to use it as a mixin”). And code is like humor. When you *have* to explain it, it’s bad code.

While I think all attempts to turn CSS into a programming language are misguided (it’s a design language, it shouldn’t take a developer’s approach — object oriented inheritance, and all that — but rather a designer’s approach) Less’s mixin syntax bothers me more than others because it doesn’t even get the programming approach right. That’s the “fatal flaw” that will keep me from using Less.

@cloudhead makes a good point later in the post. While I can certainly empathize with @cloudhead’s view of it (I don’t use Sass, either) designers “get” picky indentation rules more easily than they “get” most standard development concepts.

By: raena

raena — Thu, 02 Jul 2009 01:24:01 +0000

@Arlen, I’m utterly baffled as to how Less actually *gives you no choice* (seriously?) to write bad code. Seriously? There’s NO possible way to write decent code using this?

By: davidcroda

davidcroda — Wed, 01 Jul 2009 15:12:35 +0000

@omnicity

Sorry I guess I’m not too familiar with the way ruby works. I was assuming you could get that information via javascript or php and then pass it to the function to generate the stylesheet and link it before the page is rendered.

By: omnicity

omnicity — Wed, 01 Jul 2009 11:41:39 +0000

@Davidcroda
How do you expect a pre-processor to know how wide a users screen is?

I would love to have that in native CSS, but LESS isn’t going to be able to provide it.

By: davidcroda

davidcroda — Wed, 01 Jul 2009 10:01:18 +0000

Cool info. Can that command be run to dynamically generate perfect stylesheets based on the users screen width? That’d be neat

By: omnicity

omnicity — Wed, 01 Jul 2009 09:24:56 +0000

@Wukfit
Do you have any figures to say how much effect that has?

By: Wukfit

Wukfit — Wed, 01 Jul 2009 08:03:19 +0000

This might be slightly off topic but considering all the talk of website performance and writing faster code I though I should point out that writing css rules like this:

#banner a {...} 
#banner p {...}
#banner p a span {...}

will slow down a browsers rendering of the page due to how they perform css selector matches (right to left).