4 ms·

This looks promising and seems to address a lot of the objections I hear to compass and sass. I do really like the superset syntax approach where css is legal s

This looks promising and seems to address a lot of the objections I hear to compass and sass. I do really like the superset syntax approach where css is legal syntax in a less file. So I will be following along the development. There's still a lot of features that would be required of less to support a framework like compass. There's currently no arguments for mixins, no way to extend the language with functions that call out to code, no macro syntax allowing branching/looping and generation of selectors and properties. Such features aren't needed by your average user writing their own content, but they are absolutely core to building reusable design that can be configured and applied to your code using a simple and intuitive interface. Anyways, it's really great to see new ideas and innovation in the css compiler space. We all win as these ideas mature and gain acceptance in the web development community. -chris eppstein (sass core team)

cloudhead 17y ago
Great to have you on board! Compass was definitely one of the inspirations behind Less. Unlike Compass, though, I'd like to keep it small, as it is and as close to CSS as possible, so the more complex features of Compass probably won't find their way in Less, unless they fit the ideal.
- chriseppstein 17y ago
  I know the distinction between Sass and Compass is blurred for many folks, much like ruby and rails. Compass is libraries and tools to provide project management and community features, sass is the syntax that makes compass possible. Compass could be built on any css syntax with a comparable feature set to sass. So my point was that until you provide those more heavyweight features in the core language, you cannot have a framework like compass. Frameworks drive adoption, so think about that decision carefully. Having powerful features doesn't force them to be used, but not having them, creates limitations.
  - cloudhead 17y ago
    'Having more features doesn't force them to be used' — correct, but it changes the perception people have of the tool, as well as what they start to expect from it. I personally favor smaller tools which do the least amount possible while still fulfilling your needs. That's why, for example, I'm not a huge fan of Rails, and would much rather use Sinatra when I can. I know I'm not the only one. It's this sort of overhead I'm trying to avoid. Less is very straightforward, and I want to keep it that way—there's not much you need to learn to start using it, and the code base is tiny. For most use cases I think the feature-set will be more than enough, and if it's not, we have Compass.
    - chriseppstein 17y ago
      You're still confusing sass and compass. Like I said, your current feature set is ample for the 95% use case of normal web development. To that end, we are in complete agreement. I don't know how familiar you are with blueprint, but the less syntax doesn't support creating new abstractions that simplify design. In sass using the compass port of blueprint we can do this: #sidebar +column(8) which generates: #sidebar { float: left; margin-right: 10px; width: 310px; } The column mixin is defined here: http://github.com/chriseppstein/compass/blob/master/frameworks/blueprint/stylesheets/blueprint/modules/_grid.sass#L101 http://github.com/chriseppstein/compass/blob/master/framewor... So what could be the equivalent less syntax for this? div#sidebar { .column: 8; } This is wonderfully easy for end users, but the language syntax has to become more complicated to support it. You have to be able to specify the arguments for the mixin. Also, you need a way to refer to the parent selector within the mixin abstractly. In sass we use the & symbol to represent the selector's context. I don't know what a "css-like" syntax would be for these capabilities. I would argue that they don't really have to be that "css-y", but they just have to play nicely with existing CSS syntax, because normal users don't need them. Anyways, it's your project... But I've spent the last year thinking about these sorts of issues. If you want to discuss further, you can hit me up on github. -chris
    - 9oliYQjP 17y ago
      I think you made the right call. CSS isn't complex enough to need a framework. In a lot of cases, CSS frameworks abuse the primary motivating factor for trying to separate style and content in the first place. If I have to use particular HTML markup or class naming conventions, I may as well just forego the separation of content and style altogether and use table layouts. But less appears to make desperately needed additions that should ultimately show up in CSS itself IMHO. Certainly when I was first picking up CSS -- given my programming background -- I was reaching for the concept of variables and in fact was surprised that they did not exist in CSS. For that reason, I'd consider less to be more of a language extension than a framework.

cloudhead 17y ago

Great to have you on board! Compass was definitely one of the inspirations behind Less. Unlike Compass, though, I'd like to keep it small, as it is and as close to CSS as possible, so the more complex features of Compass probably won't find their way in Less, unless they fit the ideal.

chriseppstein 17y ago
I know the distinction between Sass and Compass is blurred for many folks, much like ruby and rails. Compass is libraries and tools to provide project management and community features, sass is the syntax that makes compass possible. Compass could be built on any css syntax with a comparable feature set to sass. So my point was that until you provide those more heavyweight features in the core language, you cannot have a framework like compass. Frameworks drive adoption, so think about that decision carefully. Having powerful features doesn't force them to be used, but not having them, creates limitations.
- cloudhead 17y ago
  'Having more features doesn't force them to be used' — correct, but it changes the perception people have of the tool, as well as what they start to expect from it. I personally favor smaller tools which do the least amount possible while still fulfilling your needs. That's why, for example, I'm not a huge fan of Rails, and would much rather use Sinatra when I can. I know I'm not the only one. It's this sort of overhead I'm trying to avoid. Less is very straightforward, and I want to keep it that way—there's not much you need to learn to start using it, and the code base is tiny. For most use cases I think the feature-set will be more than enough, and if it's not, we have Compass.
  - chriseppstein 17y ago
    You're still confusing sass and compass. Like I said, your current feature set is ample for the 95% use case of normal web development. To that end, we are in complete agreement. I don't know how familiar you are with blueprint, but the less syntax doesn't support creating new abstractions that simplify design. In sass using the compass port of blueprint we can do this: #sidebar +column(8) which generates: #sidebar { float: left; margin-right: 10px; width: 310px; } The column mixin is defined here: http://github.com/chriseppstein/compass/blob/master/frameworks/blueprint/stylesheets/blueprint/modules/_grid.sass#L101 http://github.com/chriseppstein/compass/blob/master/framewor... So what could be the equivalent less syntax for this? div#sidebar { .column: 8; } This is wonderfully easy for end users, but the language syntax has to become more complicated to support it. You have to be able to specify the arguments for the mixin. Also, you need a way to refer to the parent selector within the mixin abstractly. In sass we use the & symbol to represent the selector's context. I don't know what a "css-like" syntax would be for these capabilities. I would argue that they don't really have to be that "css-y", but they just have to play nicely with existing CSS syntax, because normal users don't need them. Anyways, it's your project... But I've spent the last year thinking about these sorts of issues. If you want to discuss further, you can hit me up on github. -chris
  - 9oliYQjP 17y ago
    I think you made the right call. CSS isn't complex enough to need a framework. In a lot of cases, CSS frameworks abuse the primary motivating factor for trying to separate style and content in the first place. If I have to use particular HTML markup or class naming conventions, I may as well just forego the separation of content and style altogether and use table layouts. But less appears to make desperately needed additions that should ultimately show up in CSS itself IMHO. Certainly when I was first picking up CSS -- given my programming background -- I was reaching for the concept of variables and in fact was surprised that they did not exist in CSS. For that reason, I'd consider less to be more of a language extension than a framework.