16 ms·

Less.js will obsolete CSS

202 points by edanm 16y ago

rriepe 16y ago
Looks interesting. I don't know how many times I wished I could define a color like thatin CSS. I'll definitely be keeping an eye on this.
lowkey 16y ago
Admitedly, I'm a relative n00b when it comes to development but seriously "I do not get it". There doesn't appear to be much in the way of reduced syntax, at least not in the example provided. Can someone explain why this is better or clearer than CSS?
- weego 16y ago
  There is genuinely a tiny benefit because you don't need to declare colors etc more than once, everything else about it is trying to wedge ideas from other areas of programming into a language that contains so many abstract concepts as to not benefit from it at all. I've worked as a UI developer for 12 years now and I wouldn't go near something like this because there is no value. At least the server side version you can pre-process and package up for live after your developers have saved literally minutes by using it. You need to know CSS inside out, so you have to then unlearn and relearn different parts just to do something you can already do with find + replace. And worse, you are even including and downloading files that the browser cannot even interpret itself without relying on another download of JavaScript as well, so you're giving something that works 100% of the time (assuming someone has CSS on) another point of failure. Most of my time in UI has been in public sector education trying to push standards and quality from various suppliers to the Govt and seeing things like this from said suppliers (I've seen worse to be fair, but I've seen something like this before) is always an unpleasant experience.
  - edanm 16y ago
    Let me give an example use case, something I've wanted. Lots of developers will tell you that it's fine to use systems like the 960 Grid System for rapid prototyping, but you shouldn't use them for final, "production" sites. Their argument is that "littering" your code with classes like "grid_4", etc. is not semantic (and they're right). So here's what I would love to do: use a system like 960 in development, but instead of using names like "grid_4", use actual, semantic names. But behind the scenes, I'll use less to "inherit" the grid_4 properties into the semantic name. E.g., assuming I have: "<div class="grid_4 article_header>", I'll remove grid_4, but use less to make "article_header" inherit grid_4's properties. That way my html remains semantic, but I get the full power of systems like 960.gs.
    - isleyaardvark 16y ago
      I'll give another example with mixins: clearfix. I've seen webpages littered with class="clearfix" all over the HTML. That doesn't do anybody any good. With a CSS preprocessor you can define a clearfix mixin and just write it something like: .class-name .clearfix font-size: 1.2em There are other ways to do it like one long string of selectors followed by the clearfix code, but they're not as convenient or readable.
    - mhd 16y ago
      Isn't that basically what compass does? http://compass-style.org/ http://compass-style.org/
- edanm 16y ago
  There aren't many features, but they fill in various "holes" in CSS (compared to every other programming language). For one example, you can define "constants". That means you can define a color once with a name (say, LINK_COLOR = #aaa), then use that name over and over. Then, if you ever feel like changing that color, you only have to change it once (where it says LINK_COLOR = ), not every time. Other benefits are something akin to "functions", and ways of "nesting" your CSS which automatically makes certain classes only apply to nested elements (this is something most people do anyway, they just do it by hand).
- jarin 16y ago
  It might not seem all that great from the simple example provided, but Compass (http://compass-style.org/ http://compass-style.org/, uses SASS) is a great example of how mixins can make your life so much easier. For example, if you want to make an inline list it's as easy as: li +inline-list
- fadeyev 16y ago
  LESS or Sass are great in specific use cases. They're especially useful when you're using a lot of CSS visuals (where you have to write out about 3-5 lines just for one property because each browser has it's own version, i.e. -moz-, -webkit-, etc). With LESS you can create a mixin that does this thing (e.g. rounded corners) that also takes an argument and just call it in all the places where you need rounded corners. Sometimes you want to re-use the same color over in many different places. If you change your mind, you have to go back and change it everywhere, making sure you don't miss a spot. Nesting makes the code much more organized (you have to try it to see) since you can see which bit of code relates to which area of the page. It's just neater and easier to view. Each of these benefits on its own isn't very big, but when you start saving time here and there they do add up, especially on large stylesheets. Basically, it's not really about reducing syntax or size of the file (which does get smaller for large stylesheets), it's all about making the stylesheet easier to build and maintain.
baddox 16y ago
Literally the only problem with CSS itself is that it doesn't have defines. Every other problem is just browser implementations.
- KevinMS 16y ago
  I also have issues with the "box model." Judging by the popularity of grid layout systems like blueprint and 960 I think others also do. The box model is fine when you just need to "flow" things around things, like text around images, and typical blog designs, but when you develop complicated interfaces it really shows its limitations and costs many hours of frustrating effort.
  - noibl 16y ago
    Not sure if this is what you're referring to, but you can have a box model that includes padding and border in the width using CSS3: box-sizing: border-box with -ms- (IE8), -moz- and -webkit- prefixes. http://www.quirksmode.org/css/box.html http://www.quirksmode.org/css/box.html
    - KevinMS 16y ago
      http://www.w3.org/TR/css3-box/ http://www.w3.org/TR/css3-box/
      - stan_rogers 16y ago
        Right CSS version, wrong module: http://www.w3.org/TR/css3-ui/#box-sizing http://www.w3.org/TR/css3-ui/#box-sizing The CSS3 UI module is a candidate recommendation. Setting: box-sizing: border-box; essentially puts the CSS box model render mode to where it was in IE5 (which is, frankly, the only sensible way to do it). Right now, it is available with Mozilla, Webkit and Microsoft prefixes (as are most of the UI module properties).
  - baddox 16y ago
    Isn't CSS3 supposed to fix that or at least give us another option? I should have specified that I was referring to CSS3.
KevinMS 16y ago
I cranked out something similar to this years ago called in Lua and C called moonfall, actually more powerful because it was extendable, even got on smashing magazines "best of the month" or something like that, and I'm pretty sure it didn't obsolete CSS. Actually I don't think anybody used it, not even me. Maybe because Lua didn't have the buzz that javascript has now. http://moonfall.org/ http://moonfall.org/
- draegtun 16y ago
  Moonfall did (at least) inspire someone to write a Perl port of it: http://search.cpan.org/dist/CSS-Moonfall/ http://search.cpan.org/dist/CSS-Moonfall/
- jsharpe 16y ago
  Ideas like this could, eventually, actually obsolete CSS as we know it. All it would take is for subsequent revisions of the CSS standard to include support for some of these features, and for browsers to support more complicated CSS. With Less, SASS and similar tools becoming more popular recently, I wouldn't be surprised to see Chrome or Firefox experimentally include their own implementations.
mjs 16y ago
Does the preprocessor generate raw (i.e. conventional) CSS, which it then convinces the browser to evaluate or re-evaluate as necessary, or does it actually apply the styles itself with JS? i.e. something equivalent to jQuery('.heading').css("color", "red").
- fadeyev 16y ago
  Conventional CSS
SingAlong 16y ago
I hope they still maintain the ruby gem version of LESS. LESS is beautiful as it is. But processing LESS code in the browser would mean that I can't use LESS.js for mobile web apps. Although there are mobile devices with 1ghz processors already out in the market, there is still a lag in rendering mediocre-weight pages that contain js on mobile devices. P.S: Congrats on keeping LESS simpler.
- stevelosh 16y ago
  You can run less.js from the command line to precompile if you have Node.js installed, and it's much faster than the Ruby gem.
benbeltran 16y ago
I don't know. As a fan of CSS I don't really "get" Less.js ... Sure I understand the benefit of defining certain properties, but are the benefits good enough to warrant depending on an additional javascript library for something like this? What happens if people block javascript? I don't know. It's not bad, but it's not for me. But going as fas as to say it will obsolete CSS, that's just too much.
- nailer 16y ago
  > are the benefits good enough to warrant depending on an additional javascript library for something like this? What happens if people block javascript? Nothing, in production you'd use the compiled ver. The article should make this clearer though.
  - edanm 16y ago
    That depends. The "new" version they talk about in the article does require Javascript, since it does on-the-fly compiling. For the current version you're right.
    - nailer 16y ago
      I understand the thing they just released allows on-the-fly compiling. I'm just suggesting is that since the existing options remain available, you can still use them.
- rimantas 16y ago
  The early implementation of CSS in Netscape relied on Javascript. That was no fun.
axod 16y ago
Sensationalist link-bait headlines have no place here IMHO.
- perlpimp 16y ago
  i've stopped reading slashdot for that reason.
- cubicle67 16y ago
  59 points and (at the time of writing) top post would indicate some disagree
  - muuh-gnu 16y ago
    Provided HN was meant to be a non-discriminatory democracy, but it to my knowledge was not. Any news site not systematically filtering content to suit a specific, targeted demographic will sooner or later inevitably converge against Digg (or die like the usenet).
  - trop 16y ago
    It's interesting looking at his code (http://github.com/cloudhead/less.js/blob/master/dist/less-1.0.20.js http://github.com/cloudhead/less.js/blob/master/dist/less-1....). It's clear, well described, and ambitious.
  - axod 16y ago
    Of course they do. That's the problem with democracies. They all turn into a cesspit of idiocy unless you keep control.
- wehriam 16y ago
  But what a headline! I left the article disappointed, but it's hard to fault the care that went into those four words. I welcome sensationalist link-bait headlines if they have weight behind them. Don't blame the sizzle, blame the steak.
jomohke 16y ago
We used Less for a project, but ended up moving to Sass: http://sass-lang.com/ http://sass-lang.com/ The Sass compiler was (is?) more mature, and the language feels more consistent (see the '&' operator in Sass vs the :hover special case in Less). The editor/tool support was quite a bit better too. Sass doesn't have a javascript in-browser implementation (afaik), but for rapid development it can watch a folder/file for changes and automatically recompile to static CSS files. Plus there's a firebug plugin, so you get Sass line numbers / references instead of compiled CSS line numbers: https://addons.mozilla.org/en-US/firefox/addon/103988/ https://addons.mozilla.org/en-US/firefox/addon/103988/
- perlpimp 16y ago
  There is sass in node.js/express framework. cant see why it cant ne adjusted to be use client side.
  - nex3 16y ago
    Unfortunately, sass.js is pretty incomplete and has no support for SCSS.
- rapind 16y ago
  Interesting. I tried both and now use LESS with the More plugin in my rails app. I'm a huge fan of HAML, but I haven't fallen in love with SASS yet. The big upside to LESS is it still looks like CSS. Compass is interesting though, from the SASS side. http://github.com/chriseppstein/compass http://github.com/chriseppstein/compass
  - jomohke 16y ago
    The latest version of Sass (3.0) has CSS syntax: The compiler supports both variants - the file extension (.scss vs .sass) denotes which you want to use. See the examples on their front page: http://sass-lang.com http://sass-lang.com They have a command line tool "sass-convert", which can convert between the syntaxes (and from Less)
ivanzhao 16y ago
instead of learning new abstraction like this, maybe more useful to sharpen up text editor skills? I found css very vim-friendly
- humbledrone 16y ago
  That's like saying that instead of learning how to write functions, one should just get better at copying and pasting (because VIM is good at that).
  - vog 16y ago
    CSS has very flexible selectors, so in a sense it already has some abstraction features. Those differ from what we know from other languages, but they are still very useful and should be exploited. I was never forced to define important colors more than twice in my CSS style sheets, usually defining them just once. Maybe my document structures are too simple to get into trouble - but maybe that's the whole trick. (i.e. producing less bloat rather than making bloat more manageable.)
    - chc 16y ago
      Complexity is not all bloat. For a given set of data with a given list of goals, there's an optimal level of complexity. More than this and it's bloat — but less than this and you're not accomplishing what you set out to do.
      - vog 16y ago
        There's still a maximum level of complexity for presentations (here: HTML presentation of a set of data). That level is independent of the content. Anything above that is just irritating for the viewing persons. This is especially true for web sites which should at least look as simple as possible. So in principle, there should be always a way to produce HTML whose DOM structure isn't too complicated, no matter what the content is.
    - humbledrone 16y ago
nex3 16y ago
Running a compiler in the browser in production will never be a good idea. If you care about the speed that your website displays -- and you should -- the slowdown caused by parsing, processing, and concatenating large amounts of CSS will dwarf over-the-wire time. People who seriously care about the usability of their sites have been spending a lot of effort recently figuring out how to get load times as fast as possible, and this is a leap in the wrong direction.
- twobar 16y ago
  less and sass both allow you to compile to css. The live, in browser compiler is just intended to speed up development.
  - nex3 16y ago
    The article makes it sound like the author expects in-browser processing to be the only way it'll be used: "Less.js is a JavaScript implementation of LESS that’s run by your web browser. As any JavaScript, you include a link to the script in your HTML, and…that’s that. LESS is now going to process LESS code so instead of including a link to a CSS file, you’ll include a link directly to your LESS code. That’s right, no CSS pre-processing, LESS will handle it live." No mention that that would be ineffective for a production site. In fact, he claims that live processing won't have noticeable lag, which is just false.
    - LaPingvino 16y ago
      I demand a benchmark. Saying that something is just false without numbers to back it up is not something I have high trust in, and is the start of the gossip that causes internet wars. First back it up with numbers, then we talk.
      - richbradshaw 16y ago
        As it's cached, it's only the first load that will have the lag. I'd guess it will be quite small as well. If the CSS makes heavy use of mixins and the nesting ability then the lag may even be smaller than the time to transfer the compiled CSS. Maybe.
vog 16y ago
One thing puzzles me: If LESS is essentially a template language specialized for CSS, why not reuse the template engine that you use in your application anyway? That way, you'd also have the benefit of defining often-used attribute values (e.g. colors) in a variable, and you could also group often-used combinations of attributes together in a variable or sub template.
- edanm 16y ago
  I wonder why there is no general "template" language that you can use on any text/source file. For example, I'm writing a lot of AutoHotKey code lately, and I find myself wishing I had some of the expressive power of Python so I wouldn't have to repeat things. I'm seriously considering writing a Python-based "Preprocessor" language which lets me drop in Python code on any file, and deals with transforming it into the final "compiled" file.
  - vog 16y ago
    > I'm seriously considering writing a Python-based "Preprocessor" language which lets me drop in Python code on any file You are probably interested in Pyratemp – a simple, well-designed and well-documented template engine that allows arbitrary Python expressions: http://www.simple-is-better.org/template/pyratemp.html http://www.simple-is-better.org/template/pyratemp.html BTW, I personally use the XSLT template language. It is language independent, but still extendable with user-defined functions written in the programming language of your application. Note that despite its name, XSLT does not only provide for XML output, but handles text output and HTML as well. In Python, you can find a excellent XSLT processor in the 4suite package: http://4suite.org/docs/CoreManual.xml#xslt_engine http://4suite.org/docs/CoreManual.xml#xslt_engine However, the syntax of XSLT is a bit clumsy, so I'll probably switch to XQuery in the future.
  - draegtun 16y ago
    I wonder why there is no general "template" language that you can use on any text/source file Template Toolkit is such a beast: http://template-toolkit.org/ http://template-toolkit.org/ Beyond its normal Perl (and Python) web templating usage I've also used (and abused) TT for: * All my static websites * CSS (dynamic and static) * Pre-process scripts (including Javascript) * Multi-lingual email * Creating (end user) configurable data exports (eg. CSV). * Websurvey language! * And probably other things I've (hopefully!) forgotten :) NB. See "ttree" & "tpage" in docs for standalone usage.
oladon 16y ago
Obsolete isn't a verb.
- portman 16y ago
  Says who? http://www.merriam-webster.com/dictionary/obsoleted http://www.merriam-webster.com/dictionary/obsoleted http://en.wiktionary.org/wiki/obsolete http://en.wiktionary.org/wiki/obsolete
  - trebor 16y ago
    Obsolete is a verb, but it is a poor choice. A better choice would be obsolesce, as in: "LESS.js will obsolesce CSS". This is because LESS.js won't obsolete CSS, but it may well start the industry on the path. Obsolete has a feeling of immediacy to it, and obsolesce has a feeling of lethargy or a gradual process which is why it's the better choice. It's an opinion, take it with a grain of salt. (BTW, I dislike MW because it takes all nuance out of the language and dumbs it down to an inexpressive mess.)
    - commieneko 16y ago
      "Mr. Wolfe is in the middle of a fit. It's complicated. There's a fireplace in the front room, but it's never lit because he hates open fires. He says they stultify mental processes. But it's lit now because he's using it. He's seated in front of it, on a chair too small for him, tearing sheets out of a book and burning them. The book is the new edition, the third edition, of Webster's New International Dictionary, Unabridged, published by the G. & C. Merriam Company of Springfield, Massachusetts. He considers it subversive because it threatens the integrity of the English language. In the past week he has given me a thousand examples of its crimes. He says it is a deliberate attempt to murder the — I beg your pardon. I describe the situation at length because he told me to bring you in there, and it will be bad."
    - danieldon 16y ago
      Obsolete is a verb, but it is a poor choice. A better choice would be obsolesce, as in: "LESS.js will obsolesce CSS" "Obsolete" is the correct word because it's a transitive verb (eg, [subject] obsoletes [object]), while obsolesce is an intransitive verb (eg, [subject] obsolesces).
mmaunder 16y ago
Oh cool, another layer of abstraction.
tjogin 16y ago
Sure, and PHP will obsolete HTML.
- adamdecaf 16y ago
  for (var $i = 0; $i < count($nav_links); $i++) { echo '<li><a href="' . $nav_links[$i] . '"></a></li>'; } I can see it now, a day without HTML! </sarcasm>
sams99 16y ago
Great, now my web pages will look like rubbish when people disable javascript
Kilimanjaro 16y ago
Def, we need def in css. Def initely
kellishaver 16y ago
I can see it being somewhat useful as a server-side technology or as an authoring tool that you can then "compile" to CSS. CSS is so straightforward and simple to use as-is, however, that I don't really think it needs something to make it even easier, although the support for variables is quite nice. Having said that, I have the same problem with LESS.js that I have with various other JavaScript layout techniques - I simply don't like relying on JavaScript to control the look and feel of a web page. I think it's awkward, inefficient, and just asking for trouble. Mostly, I also think it's completely unnecessary.
- IgorPartola 16y ago
  CSS is far from easy to use correctly. CSS is very poorly designed. Aside from all the browser hacks it's core constructs often times contradict each other (think float vs position). We do need something better but I'm not sure if LESS is it. I would much rather see something built into browsers directly.
  - kellishaver 16y ago
    I hear this all the time and I really just don't see it. I'm not trying to be argumentative, I just don't understand. Yes, it is poorly designed, no question about that and there are certainly things that could be done better, and one shouldn't have to use all of the "hacks" to begin with. But I do find it incredibly easy to work with, and I'm often doing very complex layouts that have to work in everything from IE6 up. CSS is just a matter of memorization. So I still don't think something like LESS or SASS is the answer. My point was CSS is, despite its poor design, fundamentally easy to understand in terms of how it's supposed to work. No, it doesn't always work like it's supposed to and sometimes you have to work around that, but at its core, the syntax, the structure, and methodology behind it are dead simple. Building something like LESS/SASS to run on top of/underneath CSS to then generate said CSS markup seems redundant, when instead what needs to happen is that the focus needs to be on fixing the flaws of CSS, not adding another layer of abstraction. And how does LESS/SASS handle all of those hacks? You still have to do them. You just write them a bit differently. So really, besides variables, what added value does it provide?
nathansobo 16y ago
I've tried css-dryer, which is similar in concept to server side LESS and SASS. I found it to be problematic on a large project because even though the CSS was compact in its source form, what actually got compiled ended up getting huge. It was slow to download and inefficient for the browser to process. The brevity of the source language ended up being an invitation to use CSS in a style was extremely verbose upon compilation. It also added operational complexity to have to deal with compiling the css. For example we wanted to use CSS in some of our javascript tests and then we had to deal with running the dryer from the test server. We eventually ripped it out at fairly great cost and went back to vanilla css, where it was clear to everyone what everything meant and we didn't have to worry about a huge inflation of the code. Maybe there's something smarter about these frameworks that avoids these issues?
risotto 16y ago
Sensationalist headline but I can't wait to try this. When you start representing everything as JSON trees, web programming gets so much more consistent, compact, and easier. Also see: MongoDB - save data in BSON (binary JSON) And query with JSON Node.js - Build an entire smoking fast server side web app with JavaScript objects. Bonus: run a node app on Heroku to compile and varnish cash less.js if you are worried about performance Mustache.js or Pure - JavaScript templating to turn JSON into HTML V8, tracemonkey, Nitro - blazing fast JS interpreters everywhere that will .eval JSON Convergence anyone?
whughes 16y ago
Please, no. This is terrifying. Let us browse without JavaScript and in peace. Please.
- rrhyne 16y ago
  To me that's like saying let us browse without CSS in peace.
  - chbarts 16y ago
    CSS isn't a security hole. CSS doesn't actively disrupt my preferred web workflow.
  - jufemaiz 16y ago
    Browsing without v interacting without may be a better way to view it.
- chc 16y ago
  You can still browse without Javascript. This won't hide any content — you just won't have Javascript gussying up the presentation for you. Which is already the case on a lot of sites that don't use it as a CSS replacement. That is basically your choice if you choose to roll without Javascript.
  - chbarts 16y ago
    The problem is that people already use CSS to make their sites legible. Tying CSS to Javascript would just be one more step back down the road of "Render it my way or not at all" we all hated back in the "Best Viewed With" 1990s.
bodytitle 16y ago
Is this really solving a problem? I mean CSS itself has issues but wrapping a developer centric toolkit around it doesn't seem to help. In my view CSS is a necessary evil but it is also primarily used by designers. Forcing them to use variables and learn classes and adhere to another syntax would seem counter productive to most of the gains.
loup-vaillant 16y ago
What if the user uses noscript, or otherwise disable Javascript? Preventing cautious people from seeing the eye candy doesn't sound like a good idea.
- jufemaiz 16y ago
  Or if your script(s) end up on a blacklist (ala AdBlock)…
- huhtenberg 16y ago
  Users running noscript are typically prepared for any site to look broken or not work as expected. They also comprise a tiny majority of visitors, so for all practical intents and purposes accommodating their case is not really a development priority.
  - loup-vaillant 16y ago
    I understand your point of view. But you will agree that a CSS preprocessor in Javascript is a problem: (1) It's useless. Just pre-process the style sheets statically. No need for PHP, Ruby or any server side dynamic scripting whatsoever. It's simpler, and yields less requirements for everyone. (2) It exclude users. Not only the paranoid ones that run noscript and adBlock, but also the ones that just don't have Javascript like Dillo users. (Dillo is interesting for old, weak computers.) That's still a tiny minority, but they do exist. Something useless that exclude users clearly isn't the best tool for the job. Unless punishing noscript users is a feature… Now, of course javascript is more capable than (pre-processed) CSS alone. But the article didn't seem to use those capabilities.
  - nex3 16y ago
    Don't forget the accessibility considerations: screenreaders typically don't run Javascript either.
    - loup-vaillant 16y ago
      Yes, but screen readers don't care about CSS either.
chbarts 16y ago
This will serve to break pages for those who don't blindly run code from the Internet, which is like making those websites dependent on blindly trusting pills you find in the street.
folktales 16y ago
BTW, the fix for Chrome is to start it with --disable-web-security.
duairc 16y ago
Nonsense about obsoleting CSS aside, I've downloaded this Javascript version and I've been using it as a standalone program with Node. The command-line tool is a lot less mature than the Ruby version, but it's so much faster. The Ruby one was really painfully slow. It was really frustrating to have to wait a whole five seconds for it to regenerate your CSS files every time you make a small little change. This one will regenerate your CSS in comfortably less than a second. It's much better.

202 points by edanm 16y ago

Looks interesting. I don't know how many times I wished I could define a color like thatin CSS. I'll definitely be keeping an eye on this.

lowkey 16y ago

Admitedly, I'm a relative n00b when it comes to development but seriously "I do not get it". There doesn't appear to be much in the way of reduced syntax, at least not in the example provided. Can someone explain why this is better or clearer than CSS?

weego 16y ago
There is genuinely a tiny benefit because you don't need to declare colors etc more than once, everything else about it is trying to wedge ideas from other areas of programming into a language that contains so many abstract concepts as to not benefit from it at all. I've worked as a UI developer for 12 years now and I wouldn't go near something like this because there is no value. At least the server side version you can pre-process and package up for live after your developers have saved literally minutes by using it. You need to know CSS inside out, so you have to then unlearn and relearn different parts just to do something you can already do with find + replace. And worse, you are even including and downloading files that the browser cannot even interpret itself without relying on another download of JavaScript as well, so you're giving something that works 100% of the time (assuming someone has CSS on) another point of failure. Most of my time in UI has been in public sector education trying to push standards and quality from various suppliers to the Govt and seeing things like this from said suppliers (I've seen worse to be fair, but I've seen something like this before) is always an unpleasant experience.
- edanm 16y ago
  Let me give an example use case, something I've wanted. Lots of developers will tell you that it's fine to use systems like the 960 Grid System for rapid prototyping, but you shouldn't use them for final, "production" sites. Their argument is that "littering" your code with classes like "grid_4", etc. is not semantic (and they're right). So here's what I would love to do: use a system like 960 in development, but instead of using names like "grid_4", use actual, semantic names. But behind the scenes, I'll use less to "inherit" the grid_4 properties into the semantic name. E.g., assuming I have: "<div class="grid_4 article_header>", I'll remove grid_4, but use less to make "article_header" inherit grid_4's properties. That way my html remains semantic, but I get the full power of systems like 960.gs.
  - isleyaardvark 16y ago
    I'll give another example with mixins: clearfix. I've seen webpages littered with class="clearfix" all over the HTML. That doesn't do anybody any good. With a CSS preprocessor you can define a clearfix mixin and just write it something like: .class-name .clearfix font-size: 1.2em There are other ways to do it like one long string of selectors followed by the clearfix code, but they're not as convenient or readable.
  - mhd 16y ago
    Isn't that basically what compass does? http://compass-style.org/ http://compass-style.org/
edanm 16y ago
There aren't many features, but they fill in various "holes" in CSS (compared to every other programming language). For one example, you can define "constants". That means you can define a color once with a name (say, LINK_COLOR = #aaa), then use that name over and over. Then, if you ever feel like changing that color, you only have to change it once (where it says LINK_COLOR = ), not every time. Other benefits are something akin to "functions", and ways of "nesting" your CSS which automatically makes certain classes only apply to nested elements (this is something most people do anyway, they just do it by hand).
jarin 16y ago
It might not seem all that great from the simple example provided, but Compass (http://compass-style.org/ http://compass-style.org/, uses SASS) is a great example of how mixins can make your life so much easier. For example, if you want to make an inline list it's as easy as: li +inline-list
fadeyev 16y ago
LESS or Sass are great in specific use cases. They're especially useful when you're using a lot of CSS visuals (where you have to write out about 3-5 lines just for one property because each browser has it's own version, i.e. -moz-, -webkit-, etc). With LESS you can create a mixin that does this thing (e.g. rounded corners) that also takes an argument and just call it in all the places where you need rounded corners. Sometimes you want to re-use the same color over in many different places. If you change your mind, you have to go back and change it everywhere, making sure you don't miss a spot. Nesting makes the code much more organized (you have to try it to see) since you can see which bit of code relates to which area of the page. It's just neater and easier to view. Each of these benefits on its own isn't very big, but when you start saving time here and there they do add up, especially on large stylesheets. Basically, it's not really about reducing syntax or size of the file (which does get smaller for large stylesheets), it's all about making the stylesheet easier to build and maintain.

baddox 16y ago

Literally the only problem with CSS itself is that it doesn't have defines. Every other problem is just browser implementations.

KevinMS 16y ago
I also have issues with the "box model." Judging by the popularity of grid layout systems like blueprint and 960 I think others also do. The box model is fine when you just need to "flow" things around things, like text around images, and typical blog designs, but when you develop complicated interfaces it really shows its limitations and costs many hours of frustrating effort.
- noibl 16y ago
  Not sure if this is what you're referring to, but you can have a box model that includes padding and border in the width using CSS3: box-sizing: border-box with -ms- (IE8), -moz- and -webkit- prefixes. http://www.quirksmode.org/css/box.html http://www.quirksmode.org/css/box.html
  - KevinMS 16y ago
    http://www.w3.org/TR/css3-box/ http://www.w3.org/TR/css3-box/
    - stan_rogers 16y ago
      Right CSS version, wrong module: http://www.w3.org/TR/css3-ui/#box-sizing http://www.w3.org/TR/css3-ui/#box-sizing The CSS3 UI module is a candidate recommendation. Setting: box-sizing: border-box; essentially puts the CSS box model render mode to where it was in IE5 (which is, frankly, the only sensible way to do it). Right now, it is available with Mozilla, Webkit and Microsoft prefixes (as are most of the UI module properties).
- baddox 16y ago
  Isn't CSS3 supposed to fix that or at least give us another option? I should have specified that I was referring to CSS3.

KevinMS 16y ago

I cranked out something similar to this years ago called in Lua and C called moonfall, actually more powerful because it was extendable, even got on smashing magazines "best of the month" or something like that, and I'm pretty sure it didn't obsolete CSS. Actually I don't think anybody used it, not even me. Maybe because Lua didn't have the buzz that javascript has now. http://moonfall.org/ http://moonfall.org/

draegtun 16y ago
Moonfall did (at least) inspire someone to write a Perl port of it: http://search.cpan.org/dist/CSS-Moonfall/ http://search.cpan.org/dist/CSS-Moonfall/
jsharpe 16y ago
Ideas like this could, eventually, actually obsolete CSS as we know it. All it would take is for subsequent revisions of the CSS standard to include support for some of these features, and for browsers to support more complicated CSS. With Less, SASS and similar tools becoming more popular recently, I wouldn't be surprised to see Chrome or Firefox experimentally include their own implementations.

mjs 16y ago

Does the preprocessor generate raw (i.e. conventional) CSS, which it then convinces the browser to evaluate or re-evaluate as necessary, or does it actually apply the styles itself with JS? i.e. something equivalent to jQuery('.heading').css("color", "red").

fadeyev 16y ago
Conventional CSS

SingAlong 16y ago

I hope they still maintain the ruby gem version of LESS. LESS is beautiful as it is. But processing LESS code in the browser would mean that I can't use LESS.js for mobile web apps. Although there are mobile devices with 1ghz processors already out in the market, there is still a lag in rendering mediocre-weight pages that contain js on mobile devices. P.S: Congrats on keeping LESS simpler.

stevelosh 16y ago
You can run less.js from the command line to precompile if you have Node.js installed, and it's much faster than the Ruby gem.

benbeltran 16y ago

I don't know. As a fan of CSS I don't really "get" Less.js ... Sure I understand the benefit of defining certain properties, but are the benefits good enough to warrant depending on an additional javascript library for something like this? What happens if people block javascript? I don't know. It's not bad, but it's not for me. But going as fas as to say it will obsolete CSS, that's just too much.

nailer 16y ago
> are the benefits good enough to warrant depending on an additional javascript library for something like this? What happens if people block javascript? Nothing, in production you'd use the compiled ver. The article should make this clearer though.
- edanm 16y ago
  That depends. The "new" version they talk about in the article does require Javascript, since it does on-the-fly compiling. For the current version you're right.
  - nailer 16y ago
    I understand the thing they just released allows on-the-fly compiling. I'm just suggesting is that since the existing options remain available, you can still use them.
rimantas 16y ago
The early implementation of CSS in Netscape relied on Javascript. That was no fun.

axod 16y ago

Sensationalist link-bait headlines have no place here IMHO.

perlpimp 16y ago
i've stopped reading slashdot for that reason.
cubicle67 16y ago
59 points and (at the time of writing) top post would indicate some disagree
- muuh-gnu 16y ago
  Provided HN was meant to be a non-discriminatory democracy, but it to my knowledge was not. Any news site not systematically filtering content to suit a specific, targeted demographic will sooner or later inevitably converge against Digg (or die like the usenet).
- trop 16y ago
  It's interesting looking at his code (http://github.com/cloudhead/less.js/blob/master/dist/less-1.0.20.js http://github.com/cloudhead/less.js/blob/master/dist/less-1....). It's clear, well described, and ambitious.
- axod 16y ago
  Of course they do. That's the problem with democracies. They all turn into a cesspit of idiocy unless you keep control.
wehriam 16y ago
But what a headline! I left the article disappointed, but it's hard to fault the care that went into those four words. I welcome sensationalist link-bait headlines if they have weight behind them. Don't blame the sizzle, blame the steak.

jomohke 16y ago

We used Less for a project, but ended up moving to Sass: http://sass-lang.com/ http://sass-lang.com/ The Sass compiler was (is?) more mature, and the language feels more consistent (see the '&' operator in Sass vs the :hover special case in Less). The editor/tool support was quite a bit better too. Sass doesn't have a javascript in-browser implementation (afaik), but for rapid development it can watch a folder/file for changes and automatically recompile to static CSS files. Plus there's a firebug plugin, so you get Sass line numbers / references instead of compiled CSS line numbers: https://addons.mozilla.org/en-US/firefox/addon/103988/ https://addons.mozilla.org/en-US/firefox/addon/103988/

perlpimp 16y ago
There is sass in node.js/express framework. cant see why it cant ne adjusted to be use client side.
- nex3 16y ago
  Unfortunately, sass.js is pretty incomplete and has no support for SCSS.
rapind 16y ago
Interesting. I tried both and now use LESS with the More plugin in my rails app. I'm a huge fan of HAML, but I haven't fallen in love with SASS yet. The big upside to LESS is it still looks like CSS. Compass is interesting though, from the SASS side. http://github.com/chriseppstein/compass http://github.com/chriseppstein/compass
- jomohke 16y ago
  The latest version of Sass (3.0) has CSS syntax: The compiler supports both variants - the file extension (.scss vs .sass) denotes which you want to use. See the examples on their front page: http://sass-lang.com http://sass-lang.com They have a command line tool "sass-convert", which can convert between the syntaxes (and from Less)

ivanzhao 16y ago

instead of learning new abstraction like this, maybe more useful to sharpen up text editor skills? I found css very vim-friendly

humbledrone 16y ago
That's like saying that instead of learning how to write functions, one should just get better at copying and pasting (because VIM is good at that).
- vog 16y ago
  CSS has very flexible selectors, so in a sense it already has some abstraction features. Those differ from what we know from other languages, but they are still very useful and should be exploited. I was never forced to define important colors more than twice in my CSS style sheets, usually defining them just once. Maybe my document structures are too simple to get into trouble - but maybe that's the whole trick. (i.e. producing less bloat rather than making bloat more manageable.)
  - chc 16y ago
    Complexity is not all bloat. For a given set of data with a given list of goals, there's an optimal level of complexity. More than this and it's bloat — but less than this and you're not accomplishing what you set out to do.
    - vog 16y ago
      There's still a maximum level of complexity for presentations (here: HTML presentation of a set of data). That level is independent of the content. Anything above that is just irritating for the viewing persons. This is especially true for web sites which should at least look as simple as possible. So in principle, there should be always a way to produce HTML whose DOM structure isn't too complicated, no matter what the content is.
  - humbledrone 16y ago

nex3 16y ago

Running a compiler in the browser in production will never be a good idea. If you care about the speed that your website displays -- and you should -- the slowdown caused by parsing, processing, and concatenating large amounts of CSS will dwarf over-the-wire time. People who seriously care about the usability of their sites have been spending a lot of effort recently figuring out how to get load times as fast as possible, and this is a leap in the wrong direction.

twobar 16y ago
less and sass both allow you to compile to css. The live, in browser compiler is just intended to speed up development.
- nex3 16y ago
  The article makes it sound like the author expects in-browser processing to be the only way it'll be used: "Less.js is a JavaScript implementation of LESS that’s run by your web browser. As any JavaScript, you include a link to the script in your HTML, and…that’s that. LESS is now going to process LESS code so instead of including a link to a CSS file, you’ll include a link directly to your LESS code. That’s right, no CSS pre-processing, LESS will handle it live." No mention that that would be ineffective for a production site. In fact, he claims that live processing won't have noticeable lag, which is just false.
  - LaPingvino 16y ago
    I demand a benchmark. Saying that something is just false without numbers to back it up is not something I have high trust in, and is the start of the gossip that causes internet wars. First back it up with numbers, then we talk.
    - richbradshaw 16y ago
      As it's cached, it's only the first load that will have the lag. I'd guess it will be quite small as well. If the CSS makes heavy use of mixins and the nesting ability then the lag may even be smaller than the time to transfer the compiled CSS. Maybe.

vog 16y ago

One thing puzzles me: If LESS is essentially a template language specialized for CSS, why not reuse the template engine that you use in your application anyway? That way, you'd also have the benefit of defining often-used attribute values (e.g. colors) in a variable, and you could also group often-used combinations of attributes together in a variable or sub template.

edanm 16y ago
I wonder why there is no general "template" language that you can use on any text/source file. For example, I'm writing a lot of AutoHotKey code lately, and I find myself wishing I had some of the expressive power of Python so I wouldn't have to repeat things. I'm seriously considering writing a Python-based "Preprocessor" language which lets me drop in Python code on any file, and deals with transforming it into the final "compiled" file.
- vog 16y ago
  > I'm seriously considering writing a Python-based "Preprocessor" language which lets me drop in Python code on any file You are probably interested in Pyratemp – a simple, well-designed and well-documented template engine that allows arbitrary Python expressions: http://www.simple-is-better.org/template/pyratemp.html http://www.simple-is-better.org/template/pyratemp.html BTW, I personally use the XSLT template language. It is language independent, but still extendable with user-defined functions written in the programming language of your application. Note that despite its name, XSLT does not only provide for XML output, but handles text output and HTML as well. In Python, you can find a excellent XSLT processor in the 4suite package: http://4suite.org/docs/CoreManual.xml#xslt_engine http://4suite.org/docs/CoreManual.xml#xslt_engine However, the syntax of XSLT is a bit clumsy, so I'll probably switch to XQuery in the future.
- draegtun 16y ago
  I wonder why there is no general "template" language that you can use on any text/source file Template Toolkit is such a beast: http://template-toolkit.org/ http://template-toolkit.org/ Beyond its normal Perl (and Python) web templating usage I've also used (and abused) TT for: * All my static websites * CSS (dynamic and static) * Pre-process scripts (including Javascript) * Multi-lingual email * Creating (end user) configurable data exports (eg. CSV). * Websurvey language! * And probably other things I've (hopefully!) forgotten :) NB. See "ttree" & "tpage" in docs for standalone usage.

oladon 16y ago

Obsolete isn't a verb.

portman 16y ago
Says who? http://www.merriam-webster.com/dictionary/obsoleted http://www.merriam-webster.com/dictionary/obsoleted http://en.wiktionary.org/wiki/obsolete http://en.wiktionary.org/wiki/obsolete
- trebor 16y ago
  Obsolete is a verb, but it is a poor choice. A better choice would be obsolesce, as in: "LESS.js will obsolesce CSS". This is because LESS.js won't obsolete CSS, but it may well start the industry on the path. Obsolete has a feeling of immediacy to it, and obsolesce has a feeling of lethargy or a gradual process which is why it's the better choice. It's an opinion, take it with a grain of salt. (BTW, I dislike MW because it takes all nuance out of the language and dumbs it down to an inexpressive mess.)
  - commieneko 16y ago
    "Mr. Wolfe is in the middle of a fit. It's complicated. There's a fireplace in the front room, but it's never lit because he hates open fires. He says they stultify mental processes. But it's lit now because he's using it. He's seated in front of it, on a chair too small for him, tearing sheets out of a book and burning them. The book is the new edition, the third edition, of Webster's New International Dictionary, Unabridged, published by the G. & C. Merriam Company of Springfield, Massachusetts. He considers it subversive because it threatens the integrity of the English language. In the past week he has given me a thousand examples of its crimes. He says it is a deliberate attempt to murder the — I beg your pardon. I describe the situation at length because he told me to bring you in there, and it will be bad."
  - danieldon 16y ago
    Obsolete is a verb, but it is a poor choice. A better choice would be obsolesce, as in: "LESS.js will obsolesce CSS" "Obsolete" is the correct word because it's a transitive verb (eg, [subject] obsoletes [object]), while obsolesce is an intransitive verb (eg, [subject] obsolesces).

mmaunder 16y ago

Oh cool, another layer of abstraction.

tjogin 16y ago

Sure, and PHP will obsolete HTML.

adamdecaf 16y ago
for (var $i = 0; $i < count($nav_links); $i++) { echo '<li><a href="' . $nav_links[$i] . '"></a></li>'; } I can see it now, a day without HTML! </sarcasm>

sams99 16y ago

Great, now my web pages will look like rubbish when people disable javascript

Kilimanjaro 16y ago

Def, we need def in css. Def initely

kellishaver 16y ago

I can see it being somewhat useful as a server-side technology or as an authoring tool that you can then "compile" to CSS. CSS is so straightforward and simple to use as-is, however, that I don't really think it needs something to make it even easier, although the support for variables is quite nice. Having said that, I have the same problem with LESS.js that I have with various other JavaScript layout techniques - I simply don't like relying on JavaScript to control the look and feel of a web page. I think it's awkward, inefficient, and just asking for trouble. Mostly, I also think it's completely unnecessary.

IgorPartola 16y ago
CSS is far from easy to use correctly. CSS is very poorly designed. Aside from all the browser hacks it's core constructs often times contradict each other (think float vs position). We do need something better but I'm not sure if LESS is it. I would much rather see something built into browsers directly.
- kellishaver 16y ago
  I hear this all the time and I really just don't see it. I'm not trying to be argumentative, I just don't understand. Yes, it is poorly designed, no question about that and there are certainly things that could be done better, and one shouldn't have to use all of the "hacks" to begin with. But I do find it incredibly easy to work with, and I'm often doing very complex layouts that have to work in everything from IE6 up. CSS is just a matter of memorization. So I still don't think something like LESS or SASS is the answer. My point was CSS is, despite its poor design, fundamentally easy to understand in terms of how it's supposed to work. No, it doesn't always work like it's supposed to and sometimes you have to work around that, but at its core, the syntax, the structure, and methodology behind it are dead simple. Building something like LESS/SASS to run on top of/underneath CSS to then generate said CSS markup seems redundant, when instead what needs to happen is that the focus needs to be on fixing the flaws of CSS, not adding another layer of abstraction. And how does LESS/SASS handle all of those hacks? You still have to do them. You just write them a bit differently. So really, besides variables, what added value does it provide?

nathansobo 16y ago

I've tried css-dryer, which is similar in concept to server side LESS and SASS. I found it to be problematic on a large project because even though the CSS was compact in its source form, what actually got compiled ended up getting huge. It was slow to download and inefficient for the browser to process. The brevity of the source language ended up being an invitation to use CSS in a style was extremely verbose upon compilation. It also added operational complexity to have to deal with compiling the css. For example we wanted to use CSS in some of our javascript tests and then we had to deal with running the dryer from the test server. We eventually ripped it out at fairly great cost and went back to vanilla css, where it was clear to everyone what everything meant and we didn't have to worry about a huge inflation of the code. Maybe there's something smarter about these frameworks that avoids these issues?

risotto 16y ago

Sensationalist headline but I can't wait to try this. When you start representing everything as JSON trees, web programming gets so much more consistent, compact, and easier. Also see: MongoDB - save data in BSON (binary JSON) And query with JSON Node.js - Build an entire smoking fast server side web app with JavaScript objects. Bonus: run a node app on Heroku to compile and varnish cash less.js if you are worried about performance Mustache.js or Pure - JavaScript templating to turn JSON into HTML V8, tracemonkey, Nitro - blazing fast JS interpreters everywhere that will .eval JSON Convergence anyone?

whughes 16y ago

Please, no. This is terrifying. Let us browse without JavaScript and in peace. Please.

rrhyne 16y ago
To me that's like saying let us browse without CSS in peace.
- chbarts 16y ago
  CSS isn't a security hole. CSS doesn't actively disrupt my preferred web workflow.
- jufemaiz 16y ago
  Browsing without v interacting without may be a better way to view it.
chc 16y ago
You can still browse without Javascript. This won't hide any content — you just won't have Javascript gussying up the presentation for you. Which is already the case on a lot of sites that don't use it as a CSS replacement. That is basically your choice if you choose to roll without Javascript.
- chbarts 16y ago
  The problem is that people already use CSS to make their sites legible. Tying CSS to Javascript would just be one more step back down the road of "Render it my way or not at all" we all hated back in the "Best Viewed With" 1990s.

bodytitle 16y ago

Is this really solving a problem? I mean CSS itself has issues but wrapping a developer centric toolkit around it doesn't seem to help. In my view CSS is a necessary evil but it is also primarily used by designers. Forcing them to use variables and learn classes and adhere to another syntax would seem counter productive to most of the gains.

loup-vaillant 16y ago

What if the user uses noscript, or otherwise disable Javascript? Preventing cautious people from seeing the eye candy doesn't sound like a good idea.

jufemaiz 16y ago
Or if your script(s) end up on a blacklist (ala AdBlock)…
huhtenberg 16y ago
Users running noscript are typically prepared for any site to look broken or not work as expected. They also comprise a tiny majority of visitors, so for all practical intents and purposes accommodating their case is not really a development priority.
- loup-vaillant 16y ago
  I understand your point of view. But you will agree that a CSS preprocessor in Javascript is a problem: (1) It's useless. Just pre-process the style sheets statically. No need for PHP, Ruby or any server side dynamic scripting whatsoever. It's simpler, and yields less requirements for everyone. (2) It exclude users. Not only the paranoid ones that run noscript and adBlock, but also the ones that just don't have Javascript like Dillo users. (Dillo is interesting for old, weak computers.) That's still a tiny minority, but they do exist. Something useless that exclude users clearly isn't the best tool for the job. Unless punishing noscript users is a feature… Now, of course javascript is more capable than (pre-processed) CSS alone. But the article didn't seem to use those capabilities.
- nex3 16y ago
  Don't forget the accessibility considerations: screenreaders typically don't run Javascript either.
  - loup-vaillant 16y ago
    Yes, but screen readers don't care about CSS either.

chbarts 16y ago

This will serve to break pages for those who don't blindly run code from the Internet, which is like making those websites dependent on blindly trusting pills you find in the street.

folktales 16y ago

BTW, the fix for Chrome is to start it with --disable-web-security.

duairc 16y ago

Nonsense about obsoleting CSS aside, I've downloaded this Javascript version and I've been using it as a standalone program with Node. The command-line tool is a lot less mature than the Ruby version, but it's so much faster. The Ruby one was really painfully slow. It was really frustrating to have to wait a whole five seconds for it to regenerate your CSS files every time you make a small little change. This one will regenerate your CSS in comfortably less than a second. It's much better.