I love LESS. It makes writing CSS easier, more concise, and more maintainable. I think it’s the future of CSS. But it doesn’t currently live up to its full potential in dealing with responsive design. Ethan Marcotte, in his landmark A List Apart article, wrote:
Now more than ever, we’re designing work meant to be viewed along a gradient of different experiences. Responsive web design offers us a way forward, finally allowing us to “design for the ebb and flow of things.”
There are two primary areas in which LESS could help facilitate responsive design: media queries and browser-specific styles.
Media queries
Not only can media queries be utilized to define different sets of CSS styles for different devices, but they can also be used to apply styles based on the current width of the browser, enabling the very responsive experiences of sites such as Hicksdesign.
LESS doesn’t currently provide any special support for media queries. This means that it’s impossible to embed media queries within LESS’s nested rules, forcing developers to silo their responsive styles in a separate section of the LESS document, rather than in keeping them in context. Let me give you an example of how it could work:
article {
header {
width: 50%;
@media (max-width: 720px) {
width: 100%;
}
}
}
Here we’ve set a default width of 50%. However, if the browser is less than 720px wide, we change the width to 100%. This represents what full support for media queries in LESS would look like. Unfortunately, one would have to compose the rules in this manner at present:
article {
header {
width: 50%;
}
}
@media (max-width: 720px) {
article {
header {
width: 100%;
}
}
}
This is less readable and more difficult to manage in many situations.
Browser-specific styles
A second area where LESS could be more proactive is in browser-specific styles. Historically there have been two possible methods in dealing with this problem: conditional elements and inline hacks. Conditionals are typically considered the “right” way of doing things, but they have a downside in that the browser-specific styles are far removed from their relatives. Inline hacks, on the other hand, don’t validate, but they do allow the developer to keep related styles together in one place.
LESS could deliver the best of both worlds. It could give the developer the ability to define browser-specific styles in context. Consider Paul Irish’s technique of using conditional elements to add a CSS class to the body tag:
<!--[if IE 7 ]><body class="ie7"> <![endif]-->
<!--[if IE 8]><body class="ie8"> <![endif]-->
<!--[if !IE]><!--> <body> <!--<![endif]-->
You could then write LESS similar to this:
article {
header {
width: 50%;
&&&.ie6 {
width: 49%;
}
}
}
And have it be compiled to:
article header { width: 50% }
body.ie6 article header {width: 49% }
Why is this important?
The reason I’m advocating these improvements is two-fold. To begin with, I think LESS is an amazing tool, and I want it to live up to its full potential. And secondly, I believe LESS will be the experimental underpinnings of the native CSS specifications of the future. What we do with LESS today will be what we do with CSS tomorrow.