Issues - cloudhead/less

cloudhead / less

516

Description:

Leaner CSS

Sort by: Priority | Votes | Last Updated

Loading…

109.

3 votes

feature
x

Class selectors in nested rules
16 comments Created about 1 month ago by jankrcal

Title

Body
I want to set rules for `A`, `A:hover`, `A.highlighted` and `A *.child-element`. It all relates to `A` so it makes sense to write it all inside a nested rule as follows A { color: blue; :hover { color: black; } .highlighted { color: red; } *.child-element { color: gray; } } But this gets compiled into ... A .highlighted {color: red;} A *.child-element {color: gray;} I propose that any nested selector without the name specified (e.g. `.class-name`, `:pseudo-class`, `[attribute="value"]`) relates to the parent element. At the moment, this feature works for pseudo classes but not for other selectors. I know this proposal has one major flaw - it is not backward compatible. The backward compatible but IMHO uglier alternative is to introduce a special name selector that refers to the parent. E.g. `self` or `$`. So one would have to write `self.highlighted` or `$.highlighted`. What you think?
or cancel
I want to set rules for A, A:hover, A.highlighted and A *.child-element. It all relates to A so it makes sense to write it all inside a nested rule as follows
```
A {
    color: blue;
    :hover {
        color: black;
     }
    .highlighted {
        color: red;
    }
    *.child-element {
        color: gray;
    }
}
```
But this gets compiled into
```
...
A .highlighted {color: red;}
A *.child-element {color: gray;}
```
I propose that any nested selector without the name specified (e.g. .class-name, :pseudo-class, [attribute="value"]) relates to the parent element. At the moment, this feature works for pseudo classes but not for other selectors.

I know this proposal has one major flaw - it is not backward compatible. The backward compatible but IMHO uglier alternative is to introduce a special name selector that refers to the parent. E.g. self or $. So one would have to write self.highlighted or $.highlighted.

What you think?
Comments
jtousek Tue Oct 27 06:51:34 -0700 2009 | link
I must agree with that. Let's look to this code.:

A { :hover { color: black; } .highlighted { color: red; } }

compiled:

A:hover { color: black; } A .highlighted { color: red; }

In first case there is no space, but what if a want (theoreticly) this?

A :hover { color: black; }

Well there is no chance - but i can use *:hover. - OK but the difference with space between .class and :pseudo-class is not logical.
And I never can get something like this using mixin for A

A:hover { color: black; } A.highlighted { color: red; } //without space

I think that because of incompatibility this should be changed in new major version - LESS 2.0. But I vote for this solution.:

A { :hover { color: black; } .highlighted { color: red; } }

compiled to

A :hover { color: black; } A .highlighted { color: red; }

and

A { $:hover { color: black; } $.highlighted { color: red; } }

compiled to

A:hover { color: black; } A.highlighted { color: red; }

The first case is used much more often - that's why I suggest this.
Comment
I must agree with that. Let's look to this code.: <pre> A { :hover { color: black; } .highlighted { color: red; } } </pre> compiled: <pre> A:hover { color: black; } A .highlighted { color: red; } </pre> In first case there is no space, but what if a want (theoreticly) this? <pre> A :hover { color: black; } </pre> Well there is no chance - but i can use *:hover. - OK but the difference with space between .class and :pseudo-class is not logical. And I never can get something like this using mixin for A <pre> A:hover { color: black; } A.highlighted { color: red; } //without space </pre> I think that because of incompatibility this should be changed in new major version - LESS 2.0. But I vote for this solution.: <pre> A { :hover { color: black; } .highlighted { color: red; } } </pre> compiled to <pre> A :hover { color: black; } A .highlighted { color: red; } </pre> and <pre> A { $:hover { color: black; } $.highlighted { color: red; } } </pre> compiled to <pre> A:hover { color: black; } A.highlighted { color: red; } </pre> The first case is used much more often - that's why I suggest this.
or cancel
cloudhead Thu Nov 19 09:00:55 -0800 2009 | link

.foo.bar is the same thing as .bar.foo, for that reason, it doesn't make as much sense to nest either. pseudo classes like :hover don't work that way.

Comment
`.foo.bar` is the same thing as `.bar.foo`, for that reason, it doesn't make as much sense to nest either. pseudo classes like `:hover` don't work that way.
or cancel

jankrcal Thu Nov 19 10:55:42 -0800 2009 | link

I don't get your point. Isn't .foo:hover the same as :hover.foo?

The reason for me is the clarity and elegance of the code. With my proposal, one can place all rules concerning one element into one block.

Comment
I don't get your point. Isn't `.foo:hover` the same as `:hover.foo`? The reason for me is the clarity and elegance of the code. With my proposal, one can place all rules concerning **one** element into **one** block.
or cancel
jtousek Thu Nov 19 11:46:53 -0800 2009 | link
clouhead: Yes of course, but what about this?

#header{ //global settings for page header $.page1{ //special settings for page 1 } $.page2{ //special settings for page 2 } }

Now I have to write this:

#header{ //global settings for page header } #header.page1{ //special settings for page 1 } #header.page2{ //special settings for page 2 }

I think you should agree that in this case the old way is not good enough.
Comment
clouhead: Yes of course, but what about this? <pre> #header{ //global settings for page header $.page1{ //special settings for page 1 } $.page2{ //special settings for page 2 } } </pre> Now I have to write this: <pre> #header{ //global settings for page header } #header.page1{ //special settings for page 1 } #header.page2{ //special settings for page 2 } </pre> I think you should agree that in this case the old way is not good enough.
or cancel
cloudhead Thu Nov 19 12:04:19 -0800 2009 | link
Ok, you convinced me : )

I'm thinking of something like this for the syntax:

.foo { `.bar {...} // .foo.bar .baz {...} // .foo .baz }

any objections? (it's a backtick) pseudo-classes won't change for now though, as that would break things, you can still have it both ways by doing *:hover {...}
Comment
Ok, you convinced me : ) I'm thinking of something like this for the syntax: .foo { `.bar {...} // .foo.bar .baz {...} // .foo .baz } any objections? (it's a backtick) pseudo-classes won't change for now though, as that would break things, you can still have it both ways by doing `*:hover {...}`
or cancel
jtousek Thu Nov 19 12:15:05 -0800 2009 | link

well I really don't like backtick (`), I'd prefere $ or \ or &...
about pseoudo-classes and pseudo-elements I agree

Comment
well I really don't like backtick (`), I'd prefere $ or \ or &... about pseoudo-classes and pseudo-elements I agree
or cancel

jankrcal Thu Nov 19 12:29:27 -0800 2009 | link

great :)

what about <? As a kind of opposite of the direct ancestor concatenator. But I don't mind if it is the backtick.

Comment
great :) what about `<`? As a kind of opposite of the direct ancestor concatenator. But I don't mind if it is the backtick.
or cancel
jankrcal Thu Nov 19 12:30:47 -0800 2009 | link
Example:

DIV { <.class1 {...} <.class2 {...} }
Comment
Example: DIV { <.class1 {...} <.class2 {...} }
or cancel
jtousek Thu Nov 19 12:32:09 -0800 2009 | link

I'm still against backtick. :) But I'm ok with < idea (of course $ is prefered). Let's wait for cloudhead's opinion.

Comment
I'm still against backtick. :) But I'm ok with < idea (of course $ is prefered). Let's wait for cloudhead's opinion.
or cancel
cloudhead Fri Nov 20 20:42:37 -0800 2009 | link
&.class

+ same as Sass
- quite noisy

<.class

+ could make sense as an opposit to >
- looks a little funny (nothing like it in any other language)

$.class

+ $ is unique enough
- no obvious logic behind it, a little noisy

`.class

+ very discreet
- people don't like backticks
Comment
&.class \+ same as Sass \- quite noisy <.class \+ could make sense as an opposit to `>` \- looks a little funny (nothing like it in any other language) $.class \+ `$` is unique enough \- no obvious logic behind it, a little noisy `.class \+ very discreet \- people don't like backticks
or cancel
jtousek Fri Nov 20 23:13:58 -0800 2009 | link

I agree but people have to get used to it no matter which one it'll be. Another option might be %. Well one has to be chosen and imho $ is still the best choice even if it was not originaly my but jankrcal's idea. Obvious logic isn't behind any of them (not only $ - maybe except <). Backtick in any code looks just like some wierd char which should be deleted. ;)

Comment
I agree but people have to get used to it no matter which one it'll be. Another option might be %. Well one has to be chosen and imho $ is still the best choice even if it was not originaly my but jankrcal's idea. Obvious logic isn't behind any of them (not only $ - maybe except <). Backtick in any code looks just like some wierd char which should be deleted. ;)
or cancel

thisisfranciswu Mon Nov 23 13:08:44 -0800 2009 | link

Ampersand. For serious. Please. With a cherry on top. I'm confused enough as it is switching back and forth between SASS and LESS.

Comment
Ampersand. For serious. Please. With a cherry on top. I'm confused enough as it is switching back and forth between SASS and LESS.
or cancel

jtousek Mon Nov 23 13:23:01 -0800 2009 | link

considered that, I guess & is the best after all, it is good if it's similar to SASS (even if I have no experience with it)

Comment
considered that, I guess & is the best after all, it is good if it's similar to SASS (even if I have no experience with it)
or cancel

Douwe Mon Nov 30 08:57:43 -0800 2009 | link

I vote for & or $. & would be nice because it's like in SASS, and $ would rock, just because it's $.

Comment
I vote for `&` or `$`. `&` would be nice because it's like in SASS, and `$` would rock, just because it's `$`.
or cancel

jeremyh Thu Dec 03 03:16:16 -0800 2009 | link

This is great. The inconsistency between pseudo-elements and other simple-selectors (like attribute selectors) has always bugged me.

I like the backticks. They aren't as visually noisy as the other characters.

Comment
This is great. The inconsistency between pseudo-elements and other simple-selectors (like attribute selectors) has always bugged me. I like the backticks. They aren't as visually noisy as the other characters.
or cancel

jeremyh Thu Dec 03 13:25:31 -0800 2009 | link

I've removed the paragraph. In hindsight it wasn't worth mentioning.

Comment
I've removed the paragraph. In hindsight it wasn't worth mentioning.
or cancel

Parsed with GitHub Flavored Markdown
62.

13 votes

enhancement
x

future
x

Mixin doesn't work when the class is split
13 comments Created 4 months ago by onlinesid

Title

Body
test.less: .abc { display: block; } .abc { height: 10px; } .test { .abc; } Resulted test.css: .abc { display: block; } .abc { height: 10px; } .test { display: block; } Expected result: .abc { display: block; } .abc { height: 10px; } .test { display: block; height: 10px; }
or cancel

test.less:

.abc { display: block; } .abc { height: 10px; } .test { .abc; }

Resulted test.css:

.abc { display: block; } .abc { height: 10px; } .test { display: block; }

Expected result:

.abc { display: block; } .abc { height: 10px; } .test { display: block; height: 10px; }

Comments

cloudhead Sun Aug 02 03:35:23 -0700 2009 | link

You aren't really supposed to use mixins this way, that's why.. I'll look into patching it though, because this could be interesting.

Comment
You aren't really supposed to use mixins this way, that's why.. I'll look into patching it though, because this could be interesting.
or cancel

onlinesid Sun Aug 02 03:46:10 -0700 2009 | link

I know, I simplified it just to show how to reproduce the error, but I was actually compiling blueprint's screen.css (version 0.9).

The more I see now that CSS syntax is really a mess and framework like blueprint should really be written in LESS :)

Comment
I know, I simplified it just to show how to reproduce the error, but I was actually compiling blueprint's screen.css (version 0.9). The more I see now that CSS syntax is really a mess and framework like blueprint should really be written in LESS :)
or cancel

cloudhead Sun Aug 02 04:05:49 -0700 2009 | link

Ah I see! Hopefully we start seeing some CSS 'frameworks' converted to LESS in the near future :)

Comment
Ah I see! Hopefully we start seeing some CSS 'frameworks' converted to LESS in the near future :)
or cancel

joshuaclayton Tue Aug 18 13:54:25 -0700 2009 | link

This would be immensely useful. Speaking as a maintainer of Blueprint, it's safe to say we will fully support LESS once this is implemented.

The reason why we can't right now is because of this feature. Although I understand that mixins aren't supposed to be used this way, this would allow developers to use our grid system in a semantic fashion quickly and easily.

For example, http://github.com/joshuaclayton/blueprint-css/blob/414d9242c3b3ffdf5e2d90a84c87a4c4c711a135/blueprint/screen.css#L100 shows a bulk assignment of all grid-related classes to float left and have a margin. Then, each width gets assigned a specific width.

Allowing a dev to use a mixin of .span-8 (pulling in the margin, float, and width) would be a great addition and, as I mentioned before, a deal-breaker for encouraging use of LESS.

+1

Comment
This would be *immensely* useful. Speaking as a maintainer of Blueprint, it's safe to say we will fully support LESS once this is implemented. The reason why we can't right now is because of this feature. Although I understand that mixins aren't supposed to be used this way, this would allow developers to use our grid system in a semantic fashion quickly and easily. For example, http://github.com/joshuaclayton/blueprint-css/blob/414d9242c3b3ffdf5e2d90a84c87a4c4c711a135/blueprint/screen.css#L100 shows a bulk assignment of all grid-related classes to float left and have a margin. Then, each width gets assigned a specific width. Allowing a dev to use a mixin of .span-8 (pulling in the margin, float, and width) would be a great addition and, as I mentioned before, a deal-breaker for encouraging use of LESS. +1
or cancel

cloudhead Tue Aug 18 17:20:24 -0700 2009 | link

That's reason enough for me to consider this : )

+1

Comment
That's reason enough for me to consider this : ) +1
or cancel

jonbuda Wed Aug 19 07:45:09 -0700 2009 | link

+1 this would be stellar.

Comment
+1 this would be stellar.
or cancel

timkelty Thu Aug 20 05:36:38 -0700 2009 | link

+1

Comment
+1
or cancel

erikzaadi Thu Oct 22 04:58:56 -0700 2009 | link

+1 Especially due to blueprintcss

Comment
+1 Especially due to blueprintcss
or cancel

timkelty Thu Oct 22 06:19:06 -0700 2009 | link

@cloudhead Any progress on this? Not having this feature really changes how I would ideally use less for grids, clearfixes, etc. +1 again!

Comment
@cloudhead Any progress on this? Not having this feature really changes how I would ideally use less for grids, clearfixes, etc. +1 again!
or cancel

cloudhead Thu Oct 22 07:11:11 -0700 2009 | link

I'll make it my next priority, the dynamic mixins still have some bugs to iron out.

Comment
I'll make it my next priority, the dynamic mixins still have some bugs to iron out.
or cancel

timkelty Thu Oct 22 07:33:05 -0700 2009 | link

I'll be eagerly anticipating, thanks.
Less makes life more awesome.

Comment
I'll be eagerly anticipating, thanks. Less makes life more awesome.
or cancel

grasscode Fri Nov 06 14:59:43 -0800 2009 | link

+1

Comment
+1
or cancel

chrisjowen Mon Nov 09 11:05:35 -0800 2009 | link

Yeah actually we thought that we should have done this on our .NET port. Seems sensible to support blueprint etc..

Comment
Yeah actually we thought that we should have done this on our .NET port. Seems sensible to support blueprint etc..
or cancel

Parsed with GitHub Flavored Markdown
70.

0 votes

bug
x

Error with comments
0 comments Created 4 months ago by zuf

Title

Body
Strange error with this code: div /* comment */ { color: red; } If remove comment line all works fine.
or cancel
Strange error with this code:
```
div
/* comment */
{
  color: red;
}
```
If remove comment line all works fine.
Comments

Parsed with GitHub Flavored Markdown
60.

2 votes

enhancement
x

Minus sign before a variable
1 comment Created 4 months ago by unindented

Title

Body
Less chokes if I put a minus sign before a variable: margin-left: -@width; Not a huge problem, I can work around it with: margin-left: @width * -1; Nevertheless, if it's an easy fix, it would be welcome.
or cancel
Less chokes if I put a minus sign before a variable:
```
margin-left: -@width;
```
Not a huge problem, I can work around it with:
```
margin-left: @width * -1;
```
Nevertheless, if it's an easy fix, it would be welcome.
Comments

cloudhead Sun Aug 02 03:36:15 -0700 2009 | link

Definitely something on the todo list : )

Comment
Definitely something on the todo list : )
or cancel

Parsed with GitHub Flavored Markdown
66.

1 vote

css support
x

@charset support
0 comments Created 4 months ago by nerkles

Title

Body
use of @charset rule causes syntax error. Rule is documented here: http://www.w3.org/International/questions/qa-css-charset
or cancel

use of @charset rule causes syntax error.

Rule is documented here:
http://www.w3.org/International/questions/qa-css-charset

Comments

Parsed with GitHub Flavored Markdown
71.

0 votes

css support
x

Error with data URLs.
0 comments Created 4 months ago by mcvsama

Title

Body
Example: background: url(data:image/png;base64,abc) repeat-x scroll 0 0; compiles to background: url(data:image/png;base64, abc) repeat-x scroll 0 0; Workaround: put '' around URL content.
or cancel

Example:
background: url(data:image/png;base64,abc) repeat-x scroll 0 0;
compiles to
background: url(data:image/png;base64, abc) repeat-x scroll 0 0;

Workaround: put '' around URL content.

Comments

Parsed with GitHub Flavored Markdown
79.

1 vote

css support
x

Support for CSS escaping
0 comments Created 3 months ago by sandstrom

Title

Body
// CODE div#administration div.js\:content { font-size:smaller; } // ERROR ! Syntax Error: on line 2185: expected one of . # [ ( :: : * - @media @font-face , ; { got \ after: div#administration div.js // REFERENCES http://reference.sitepoint.com/css/cssescapenotation http://dbaron.org/css/test/parsing3 http://www.w3.org/TR/CSS2/grammar.html http://www.w3.org/TR/CSS2/syndata.html
or cancel
// CODE

div#administration div.js\:content {
```
font-size:smaller;
```
}

// ERROR

! Syntax Error: on line 2185: expected one of . # [ ( :: : * - @media @font-face , ; { got \ after:

div#administration div.js

// REFERENCES http://reference.sitepoint.com/css/cssescapenotation
http://dbaron.org/css/test/parsing3
http://www.w3.org/TR/CSS2/grammar.html
http://www.w3.org/TR/CSS2/syndata.html
Comments

Parsed with GitHub Flavored Markdown
65.

0 votes

pending
x

mixins/variables from imports unavailable in other imports
6 comments Created 4 months ago by mlebarron

Title

Body
util.less @white: #FFF; .zeropad {padding: 0;} code.less img { .zeropad; } base.less @import 'util.less'; @import 'code.less'; result: ! Name Error: * is undefined. ! Name Error: * is undefined. put img { .zeropad; } in base.less instead of in code.less and it works fine change code.less to a { color: @white; } result: ! Name Error: @white is undefined.
or cancel
util.less
```
@white: #FFF;
.zeropad {padding: 0;}
```
code.less
```
img { .zeropad; }
```
base.less
```
@import 'util.less';
@import 'code.less';
```
result:
```
! Name Error: * is undefined.
! Name Error: * is undefined.
```
put img { .zeropad; } in base.less instead of in code.less and it works fine

change code.less to
```
a { color: @white; }
```
result:
```
! Name Error: @white is undefined.
```
Comments
cloudhead Wed Aug 05 07:20:20 -0700 2009 | link

That's because @import doesn't really work like an include, but more like an independent module/mixin, avoiding name conflicts with other modules.

So to use .zeropad in code.less, you would have to import util.less in code.less.

This might change in the future, if people are too confused with the behavior.. we'll see. Or I might add an @include directive.

Comment
That's because @import doesn't really work like an include, but more like an independent module/mixin, avoiding name conflicts with other modules. So to use .zeropad in `code.less`, you would have to import `util.less` in `code.less`. This might change in the future, if people are too confused with the behavior.. we'll see. Or I might add an @include directive.
or cancel
daz4126 Thu Oct 08 04:48:54 -0700 2009 | link
1 for this functionality

I think that when you are trying to create standard libraries/frameworks this comes in handy.

The usage i envisage is that you'd have one file that held all your colour definitions and others (your framework files) that contained other styles (eg grids,resets,widgets etc)

Then you would have one master.less file that imported/included ALL of the other less files and then set specific styles for the particular site you are working on.

That would mean all you would need to do is set your colours in one file, then put everything together in the other file. The framework files shouldn't be touched - just left to make their specific styles available to main.less

The proposed functionality would allow the framework files to reference the colours set in the colour file.

I hope that makes sense,

DAZ
Comment
+ 1 for this functionality I think that when you are trying to create standard libraries/frameworks this comes in handy. The usage i envisage is that you'd have one file that held all your colour definitions and others (your framework files) that contained other styles (eg grids,resets,widgets etc) Then you would have one master.less file that imported/included ALL of the other less files and then set specific styles for the particular site you are working on. That would mean all you would need to do is set your colours in one file, then put everything together in the other file. The framework files shouldn't be touched - just left to make their specific styles available to main.less The proposed functionality would allow the framework files to reference the colours set in the colour file. I hope that makes sense, DAZ
or cancel
cloudhead Fri Oct 09 08:20:25 -0700 2009 | link

that's how it currently works though..

Comment
that's how it currently works though..
or cancel
cloudhead Fri Oct 09 08:22:21 -0700 2009 | link
lib.less

@color1: #ff871a; @color2: #dd1100;

main.less

@import "lib"; a { color: @color1; }

output:

a { color: #ff871a; }

What I was saying is imports don't bleed into other imports.
Comment
lib.less @color1: #ff871a; @color2: #dd1100; main.less @import "lib"; a { color: @color1; } output: a { color: #ff871a; } What I was saying is imports don't bleed into other imports.
or cancel
mlebarron Sat Oct 10 13:08:13 -0700 2009 | link

right... but they SHOULD be available to other imports. Especially when in the docs scope is referred to as similar to programming languages, and imports work as expected.

if, as in my example, I've already defined @white as #FFF in my util file, and util is included in the parent file of code, then @white should be available in code. otherwise every file I have is going to be a big mess of imports at the top.

Plus, and this is the huge problem I have with how this works, without silent classes or having imports available to all other files, everytime I import util.less, I get yet another .zeropad class output to my final css file.

Comment
right... but they SHOULD be available to other imports. Especially when in the docs scope is referred to as similar to programming languages, and imports work as expected. if, as in my example, I've already defined @white as #FFF in my util file, and util is included in the parent file of code, then @white should be available in code. otherwise every file I have is going to be a big mess of imports at the top. Plus, and this is the huge problem I have with how this works, without silent classes or having imports available to all other files, everytime I import util.less, I get yet another .zeropad class output to my final css file.
or cancel

timkelty Thu Oct 22 06:21:09 -0700 2009 | link

+1, exactly what I was looking for!

Comment
+1, exactly what I was looking for!
or cancel

Parsed with GitHub Flavored Markdown
82.

1 vote

enhancement
x

Grouping don't work, eg. a, b, c { color: white; }
1 comment Created 3 months ago by sandstrom

Title

Body
This is an illustrative example of my problem, below is real code/output. // less a, b, c { color:white; } // css output a { color:white; } b { color:white; } c { color:white; } REAL EXAMPLE: LESS CODE div.box > h1, div.box > h2, div.box > h3, div.box > h4, div.box > h5, div.box > h6, div.box > div.header { background-color:rgb(230,230,230); padding:1em; .topRadius; } CSS RESULTS (AFTER PARSING WITH LESS) div.box > h1 { background-color: #e6e6e6; padding: 1em; -webkit-border-top-left-radius: 3px; -webkit-border-top-right-radius: 3px; -moz-border-radius-topleft: 3px; -moz-border-radius-topright: 3px; -khtml-border-top-left-radius: 3px; -khtml-border-top-right-radius: 3px; border-top-left-radius: 3px; border-top-right-radius: 3px; } div.box > h2 { background-color: #e6e6e6; padding: 1em; -webkit-border-top-left-radius: 3px; -webkit-border-top-right-radius: 3px; -moz-border-radius-topleft: 3px; -moz-border-radius-topright: 3px; -khtml-border-top-left-radius: 3px; -khtml-border-top-right-radius: 3px; border-top-left-radius: 3px; border-top-right-radius: 3px; } div.box > h3 { background-color: #e6e6e6; padding: 1em; -webkit-border-top-left-radius: 3px; -webkit-border-top-right-radius: 3px; -moz-border-radius-topleft: 3px; -moz-border-radius-topright: 3px; -khtml-border-top-left-radius: 3px; -khtml-border-top-right-radius: 3px; border-top-left-radius: 3px; border-top-right-radius: 3px; } div.box > h4 { background-color: #e6e6e6; padding: 1em; -webkit-border-top-left-radius: 3px; -webkit-border-top-right-radius: 3px; -moz-border-radius-topleft: 3px; -moz-border-radius-topright: 3px; -khtml-border-top-left-radius: 3px; -khtml-border-top-right-radius: 3px; border-top-left-radius: 3px; border-top-right-radius: 3px; } div.box > h5 { background-color: #e6e6e6; padding: 1em; -webkit-border-top-left-radius: 3px; -webkit-border-top-right-radius: 3px; -moz-border-radius-topleft: 3px; -moz-border-radius-topright: 3px; -khtml-border-top-left-radius: 3px; -khtml-border-top-right-radius: 3px; border-top-left-radius: 3px; border-top-right-radius: 3px; } div.box > h6 { background-color: #e6e6e6; padding: 1em; -webkit-border-top-left-radius: 3px; -webkit-border-top-right-radius: 3px; -moz-border-radius-topleft: 3px; -moz-border-radius-topright: 3px; -khtml-border-top-left-radius: 3px; -khtml-border-top-right-radius: 3px; border-top-left-radius: 3px; border-top-right-radius: 3px; } div.box > div.header { background-color: #e6e6e6; padding: 1em; -webkit-border-top-left-radius: 3px; -webkit-border-top-right-radius: 3px; -moz-border-radius-topleft: 3px; -moz-border-radius-topright: 3px; -khtml-border-top-left-radius: 3px; -khtml-border-top-right-radius: 3px; border-top-left-radius: 3px; border-top-right-radius: 3px; }
or cancel
This is an illustrative example of my problem, below is real code/output.

// less a, b, c { color:white; }

// css output a { color:white; }
b { color:white; }
c { color:white; }

REAL EXAMPLE:

LESS CODE
div.box > h1,
div.box > h2,
div.box > h3,
div.box > h4,
div.box > h5,
div.box > h6,
div.box > div.header {
```
background-color:rgb(230,230,230);
padding:1em;
.topRadius;
```
}

CSS RESULTS (AFTER PARSING WITH LESS)
div.box > h1 {
background-color: #e6e6e6; padding: 1em; -webkit-border-top-left-radius: 3px; -webkit-border-top-right-radius: 3px; -moz-border-radius-topleft: 3px; -moz-border-radius-topright: 3px; -khtml-border-top-left-radius: 3px; -khtml-border-top-right-radius: 3px; border-top-left-radius: 3px; border-top-right-radius: 3px; } div.box > h2 {
background-color: #e6e6e6; padding: 1em; -webkit-border-top-left-radius: 3px; -webkit-border-top-right-radius: 3px; -moz-border-radius-topleft: 3px; -moz-border-radius-topright: 3px; -khtml-border-top-left-radius: 3px; -khtml-border-top-right-radius: 3px; border-top-left-radius: 3px; border-top-right-radius: 3px; } div.box > h3 {
background-color: #e6e6e6; padding: 1em; -webkit-border-top-left-radius: 3px; -webkit-border-top-right-radius: 3px; -moz-border-radius-topleft: 3px; -moz-border-radius-topright: 3px; -khtml-border-top-left-radius: 3px; -khtml-border-top-right-radius: 3px; border-top-left-radius: 3px; border-top-right-radius: 3px; } div.box > h4 {
background-color: #e6e6e6; padding: 1em; -webkit-border-top-left-radius: 3px; -webkit-border-top-right-radius: 3px; -moz-border-radius-topleft: 3px; -moz-border-radius-topright: 3px; -khtml-border-top-left-radius: 3px; -khtml-border-top-right-radius: 3px; border-top-left-radius: 3px; border-top-right-radius: 3px; } div.box > h5 {
background-color: #e6e6e6; padding: 1em; -webkit-border-top-left-radius: 3px; -webkit-border-top-right-radius: 3px; -moz-border-radius-topleft: 3px; -moz-border-radius-topright: 3px; -khtml-border-top-left-radius: 3px; -khtml-border-top-right-radius: 3px; border-top-left-radius: 3px; border-top-right-radius: 3px; } div.box > h6 {
background-color: #e6e6e6; padding: 1em; -webkit-border-top-left-radius: 3px; -webkit-border-top-right-radius: 3px; -moz-border-radius-topleft: 3px; -moz-border-radius-topright: 3px; -khtml-border-top-left-radius: 3px; -khtml-border-top-right-radius: 3px; border-top-left-radius: 3px; border-top-right-radius: 3px; } div.box > div.header {
background-color: #e6e6e6; padding: 1em; -webkit-border-top-left-radius: 3px; -webkit-border-top-right-radius: 3px; -moz-border-radius-topleft: 3px; -moz-border-radius-topright: 3px; -khtml-border-top-left-radius: 3px; -khtml-border-top-right-radius: 3px; border-top-left-radius: 3px; border-top-right-radius: 3px; }
Comments

cloudhead Tue Sep 08 07:05:26 -0700 2009 | link

a, b, c {color:white} parses to a, b, c { color: white; } on my machine.

I'm aware of the crappy selector grouping on nested/hierarchical selectors though..

Comment
`a, b, c {color:white}` parses to `a, b, c { color: white; }` on my machine. I'm aware of the crappy selector grouping on nested/hierarchical selectors though..
or cancel

Parsed with GitHub Flavored Markdown
98.

1 vote

enhancement
x

Nested CSS Functions
0 comments Created 2 months ago by daz4126

Title

Body
Can a nested rule refer to an argument from its parent? This is what I want to do: .box(@width:200px){ width:@width; .column{margin:@width/5} } .content{.box(600px);} And this should produce: .content{width:600px;} .content .column {margin:120px;} At the moment I just get an error when I try to include any nested rules with CSS functions. cheers, DAZ
or cancel
Can a nested rule refer to an argument from its parent?

This is what I want to do:
```
.box(@width:200px){
     width:@width;
    .column{margin:@width/5}
}
.content{.box(600px);}
```
And this should produce:
```
.content{width:600px;}
.content .column {margin:120px;}
```
At the moment I just get an error when I try to include any nested rules with CSS functions.

cheers,

DAZ
Comments

Parsed with GitHub Flavored Markdown
103.

1 vote

dynamic mixins
x

Odd scope behavior in nested mixins.
1 comment Created about 1 month ago by xdissent

Title

Body
Nested mixins behave differently when the top level mixin is called with and without arguments. Here's an example: @glob: red; .setup(@outside: green) { color: @outside; background-color: @glob; .run(@inside: blue) { color: @inside; background-color: @outside; } } body { .setup(black); p { .run(white); } } Fails with: `! Variable Name Error: .run in p is undefined.`. But when the `.setup` mixin is called without arguments, everything behaves perfectly: @glob: red; .setup(@outside: green) { color: @outside; background-color: @glob; .run(@inside: blue) { color: @inside; background-color: @outside; } } body { .setup; p { .run(white); } } becomes: body { color: green; background-color: red; } body p { color: white; background-color: green; } If this worked with arguments, it would be ideal for pseudo namespacing of mixins. Since the scope resolution always falls back to the parent scope, really cool complex conditional styles could be created.
or cancel
Nested mixins behave differently when the top level mixin is called with and without arguments. Here's an example:
```
@glob: red;

.setup(@outside: green) {
    color: @outside;
    background-color: @glob;

    .run(@inside: blue) {
        color: @inside;
        background-color: @outside;
    }
}

body {
    .setup(black);

    p {
        .run(white);
    }
}
```
Fails with: ! Variable Name Error: .run in p is undefined.. But when the .setup mixin is called without arguments, everything behaves perfectly:
```
@glob: red;

.setup(@outside: green) {
    color: @outside;
    background-color: @glob;

    .run(@inside: blue) {
        color: @inside;
        background-color: @outside;
    }
}

body {
    .setup;

    p {
        .run(white);
    }
}
```
becomes:
```
body {
  color: green;
  background-color: red;
}
body p {
  color: white;
  background-color: green;
}
```
If this worked with arguments, it would be ideal for pseudo namespacing of mixins. Since the scope resolution always falls back to the parent scope, really cool complex conditional styles could be created.
Comments
daz4126 Sun Oct 18 03:04:46 -0700 2009 | link
This also doesn't work if the nested mixin does NOT have an argument (even though you'd expect it to default to blue), the error message is the same ! Variable Name Error: .run in p is undefined.:

@glob: red; .setup(@outside: green) { color: @outside; background-color: @glob; .run(@inside: blue) { color: @inside; background-color: @outside; } } body { .setup; p { .run; } }
Comment
This also doesn't work if the nested mixin does NOT have an argument (even though you'd expect it to default to blue), the error message is the same `! Variable Name Error: .run in p is undefined.`: @glob: red; .setup(@outside: green) { color: @outside; background-color: @glob; .run(@inside: blue) { color: @inside; background-color: @outside; } } body { .setup; p { .run; } }
or cancel
Parsed with GitHub Flavored Markdown
90.

0 votes

bug
x

Reimporting files clobber redefinitions
1 comment Created 2 months ago by bruce

Title

Body
The following example was tested using 1.2.8 (GitHub-hosted gem). It shows how importing a file can cause its definitions to clobber re-definitions made since the first import. Note: I prepended #s with a backslashes in the example to prevent GitHub's autolinking of issue #'s. Apparently in code blocks the backslash stays behind; it goes without saying these backslashes aren't present in my actual less/css markup. File `main.less` (importing `some-framework.css` to use `.red`): @import "some-framework.css"; body { background: \#fff; } p { .red; } @import "_secondary"; File `_secondary.less` (also importing `some-framework.css` to use `.red`): @import "some-framework.css"; td { .red; } File `some-framework.css` body { background: \#000; } .red { color: red; } This following is the output (`main.css`) of running `lessc main.less`. You can see here the second import of `some-framework.css` in `_secondary.less` has caused the _body_ background set in `main.less` to be clobbered. This is effectively a re-import. body { background: \#000000; } .red { color: red; } body { background: \#ffffff; } p { color: red; } body { background: \#000000; } .red, td { color: red; } The real world example of this problem is using a framework like blueprint, and trying to modify the background -- only to have it clobbered when you import other files (that also need blueprint to use `.column`, etc).
or cancel
The following example was tested using 1.2.8 (GitHub-hosted gem). It shows how importing a file can cause its definitions to clobber re-definitions made since the first import.

Note: I prepended #s with a backslashes in the example to prevent GitHub's autolinking of issue #'s. Apparently in code blocks the backslash stays behind; it goes without saying these backslashes aren't present in my actual less/css markup.

File main.less (importing some-framework.css to use .red):
```
@import "some-framework.css";

body { background: \#fff; }
p { .red; }

@import "_secondary";
```
File _secondary.less (also importing some-framework.css to use .red):
```
@import "some-framework.css";

td { .red; }
```
File some-framework.css
```
body { background: \#000; }

.red {
  color: red;
}
```
This following is the output (main.css) of running lessc main.less. You can see here the
second import of some-framework.css in _secondary.less has caused the body
background set in main.less to be clobbered. This is effectively a
re-import.
```
body { background: \#000000; }
.red { color: red; }
body { background: \#ffffff; }
p { color: red; }
body { background: \#000000; }
.red, td { color: red; }
```
The real world example of this problem is using a framework like blueprint, and trying to modify the background -- only to have it clobbered when you import other files (that also need blueprint to use .column, etc).
Comments
bruce Mon Sep 28 14:45:49 -0700 2009 | link
Something I did as a quick hack when I ran into this problem was to modify less.tt temporarily to output the list of files imported (at import), like this:

unless env.root.imported.include?(path) env.root.imported << path p env.root.imported # I added this -BW env.rules += Less::Engine.new(File.new(path)).to_tree.rules end

Here was the output when I ran the example I noted in this issue:

["/Users/bruce/less-test/some-framework.css"] ["/Users/bruce/less-test/some-framework.css", "/Users/bruce/less-test/_secondary.less"] ["/Users/bruce/less-test/some-framework.css"]

This makes me wonder if env.root.imported survives across files, or if it's being cleared.

Thanks!
Comment
Something I did as a quick hack when I ran into this problem was to modify `less.tt` temporarily to output the list of files imported (at import), like this: unless env.root.imported.include?(path) env.root.imported << path p env.root.imported # I added this -BW env.rules += Less::Engine.new(File.new(path)).to_tree.rules end Here was the output when I ran the example I noted in this issue: ["/Users/bruce/less-test/some-framework.css"] ["/Users/bruce/less-test/some-framework.css", "/Users/bruce/less-test/_secondary.less"] ["/Users/bruce/less-test/some-framework.css"] This makes me wonder if `env.root.imported` survives across files, or if it's being cleared. Thanks!
or cancel
Parsed with GitHub Flavored Markdown
91.

1 vote

bug
x

Variables not accepted in line-height shorthand
0 comments Created 2 months ago by avdgaag

Title

Body
Less raises a SyntaxError when using a variable for the line-height in the `font` shorthand: font: bold 12px/@line-height Arial, sans-serif; I would expect it to substitute `@line-height` with whatever its value is.
or cancel
Less raises a SyntaxError when using a variable for the line-height in the font shorthand:
```
font: bold 12px/@line-height Arial, sans-serif;
```
I would expect it to substitute @line-height with whatever its value is.
Comments

Parsed with GitHub Flavored Markdown
114.

0 votes

bug
x

Variable reference in alpha slot of rgba causes an error
0 comments Created 26 days ago by caleb

Title

Body
The following causes an error when processed with less: @op: .5; #title-bar { background-color: rgba(0, 0, 0, @op); } This is the output of lessc: /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/polyglot-0.2.9/lib/polyglot.rb:78:in `max': comparison of Less::Node::Variable with 0 failed (ArgumentError) from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/literal.rb:77:in `each' from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/literal.rb:77:in `max' from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/literal.rb:77:in `normalize' from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/literal.rb:22:in `initialize' from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/function.rb:18:in `new' from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/function.rb:18:in `rgba' from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/function.rb:77:in `send' from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/function.rb:77:in `evaluate' from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/function.rb:66:in `to_css' from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/property.rb:83:in `to_css' from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/property.rb:83:in `map' from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/property.rb:83:in `to_css' from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/element.rb:154:in `to_css' from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/element.rb:153:in `map' from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/element.rb:153:in `to_css' from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/element.rb:168:in `to_css' from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/element.rb:166:in `map' from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/element.rb:166:in `to_css' from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine.rb:47:in `to_css' from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/command.rb:57:in `parse' from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/command.rb:50:in `run!' from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/lessc:92 from /Users/caleb/Applications/ruby-1.8.7-p174/bin/lessc:19:in `load' from /Users/caleb/Applications/ruby-1.8.7-p174/bin/lessc:19
or cancel
The following causes an error when processed with less:
```
@op: .5;

#title-bar {
  background-color: rgba(0, 0, 0, @op);
}
```
This is the output of lessc:
```
/Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/polyglot-0.2.9/lib/polyglot.rb:78:in `max': comparison of Less::Node::Variable with 0 failed (ArgumentError)
    from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/literal.rb:77:in `each'
    from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/literal.rb:77:in `max'
    from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/literal.rb:77:in `normalize'
    from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/literal.rb:22:in `initialize'
    from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/function.rb:18:in `new'
    from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/function.rb:18:in `rgba'
    from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/function.rb:77:in `send'
    from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/function.rb:77:in `evaluate'
    from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/function.rb:66:in `to_css'
    from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/property.rb:83:in `to_css'
    from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/property.rb:83:in `map'
    from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/property.rb:83:in `to_css'
    from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/element.rb:154:in `to_css'
    from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/element.rb:153:in `map'
    from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/element.rb:153:in `to_css'
    from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/element.rb:168:in `to_css'
    from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/element.rb:166:in `map'
    from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine/nodes/element.rb:166:in `to_css'
    from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/engine.rb:47:in `to_css'
    from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/command.rb:57:in `parse'
    from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/../lib/less/command.rb:50:in `run!'
    from /Users/caleb/Applications/ruby-1.8.7-p174/lib/ruby/gems/1.8/gems/less-1.2.11/bin/lessc:92
    from /Users/caleb/Applications/ruby-1.8.7-p174/bin/lessc:19:in `load'
    from /Users/caleb/Applications/ruby-1.8.7-p174/bin/lessc:19
```
Comments

Parsed with GitHub Flavored Markdown
94.

0 votes

bug
x

Syntax error?
4 comments Created 2 months ago by j0hnsmith

Title

Body
This should generate a syntax error but doesn't (1.1.13) #foo { font-size: 10px; text-align: center: // s/be ; not : } #bar { height: 100px; } Not really sure if it's a problem or not.
or cancel
This should generate a syntax error but doesn't (1.1.13)
```
#foo {
  font-size: 10px; 
  text-align: center: // s/be ; not :
}
#bar {
  height: 100px; 
}
```
Not really sure if it's a problem or not.
Comments
j0hnsmith Wed Nov 04 19:11:04 -0800 2009 | link
I guess this should also be a syntax error

p { margin-botton: 20px; // s/be margin-bottom }
Comment
I guess this should also be a syntax error p { margin-botton: 20px; // s/be margin-bottom }
or cancel
cloudhead Wed Nov 18 18:57:29 -0800 2009 | link

well margin-botton isn't a syntax error, it's just a property css doesn't support : ) — I think your browser should be able to tell you that.

Comment
well `margin-botton` isn't a syntax error, it's just a property css doesn't support : ) — I think your browser should be able to tell you that.
or cancel
j0hnsmith Wed Nov 18 19:28:10 -0800 2009 | link
Of course, it's not for less to decide what are valid properties and what aren't.

This is a syntax error though?

text-align: center: // s/be ; not :
Comment
Of course, it's not for less to decide what are valid properties and what aren't. This is a syntax error though? text-align: center: // s/be ; not :
or cancel
cloudhead Wed Nov 18 21:12:11 -0800 2009 | link

yea, that is, I'm gonna look into why it's passing through.

Comment
yea, that is, I'm gonna look into why it's passing through.
or cancel

Parsed with GitHub Flavored Markdown
116.

1 vote

lessc --watch exits on error when run non-interactively
0 comments Created 20 days ago by guns

Title

Body
I sent this as a pull request, but I thought I should officially log it as an issue. It's minor, but may be helpful to others who have a similar workflow: `lessc --watch` dies on compile errors when it is run in the background: $ (lessc -w foo.less &>/dev/null) & # => doesn't stay alive This happens because the main watch loop expects input from STDIN after an error occurs. When not attached to a terminal, `STDIN.gets` receives an `EOF` and exits prematurely. The following patch branch refactors the watch loop to trap signals and always update the destination timestamp. This allows the process to run without needing any input from the user; if there's an error, just save the file again. http://github.com/guns/less/tree/guns-robust-watch (this branch contains only relevant diffs this time)
or cancel
I sent this as a pull request, but I thought I should officially log it as an issue. It's minor, but may be helpful to others who have a similar workflow:

lessc --watch dies on compile errors when it is run in the background:
```
$ (lessc -w foo.less &>/dev/null) & # => doesn't stay alive
```
This happens because the main watch loop expects input from STDIN after an error occurs. When not attached to a terminal, STDIN.gets receives an EOF and exits prematurely.

The following patch branch refactors the watch loop to trap signals and always update the destination timestamp. This allows the process to run without needing any input from the user; if there's an error, just save the file again.

http://github.com/guns/less/tree/guns-robust-watch
(this branch contains only relevant diffs this time)
Comments

Parsed with GitHub Flavored Markdown
118.

0 votes

Mixins and Variables available globally (throughout @imports)
1 comment Created 19 days ago by timkelty

Title

Body
Currently I have to maintain a constants.less file and @import it into the top of each of my files to get the variables I need available (reset.less, screen.less, forms.less etc). Less than ideal, and if I'm using with mixins, it results in duplicate code in the output. Ideally, I'd be able to import my constants.less file at the top of my reset, and import reset and forms a the top of my screen.less and all the vars and mixins from the constants.less would still be available. I'm using Less daily on every project now, and this along with issue 62: http://github.com/cloudhead/less/issues/#issue/62 would take any frustration out of it!
or cancel

Currently I have to maintain a constants.less file and @import it into the top of each of my files to get the variables I need available (reset.less, screen.less, forms.less etc). Less than ideal, and if I'm using with mixins, it results in duplicate code in the output.

Ideally, I'd be able to import my constants.less file at the top of my reset, and import reset and forms a the top of my screen.less and all the vars and mixins from the constants.less would still be available.

I'm using Less daily on every project now, and this along with issue 62: http://github.com/cloudhead/less/issues/#issue/62 would take any frustration out of it!

Comments

mechanicalchopsticks Mon Nov 30 13:32:55 -0800 2009 | link

i second this, i have a somewhat big less library and it is getting really slow on compile, i think this is because i import like 20 times the same files.

Comment
i second this, i have a somewhat big less library and it is getting really slow on compile, i think this is because i import like 20 times the same files.
or cancel

Parsed with GitHub Flavored Markdown
104.

3 votes

dynamic mixins
x

Dynamic Mixins Not Nesting Properly
4 comments Created about 1 month ago by daz4126

Title

Body
.foo(@bar:1){ div{color:red;}} #test{.foo(2);} Produces (note the rogue 'foo' that has been added to the nested property!): #test { foo div { color: red; } }
or cancel
```
.foo(@bar:1){
  div{color:red;}}

#test{.foo(2);}
```
Produces (note the rogue 'foo' that has been added to the nested property!):
```
#test {
  foo div { color: red; }

}
```
Comments
daz4126 Mon Oct 12 23:06:14 -0700 2009 | link

This is on v1.2.11 btw

Comment
This is on v1.2.11 btw
or cancel
tcjr Thu Nov 12 10:52:23 -0800 2009 | link
It looks like the mixin name is always getting added for nested children. Here's some test markup:

.box-shadow-mixin (@h: 0, @v: 0, @blur: 0, @color: none) { box-shadow: @h @v @blur @color; -moz-box-shadow: @h @v @blur @color; -webkit-box-shadow: @h @v @blur @color; h1 { background-color: @color; } } .random-box { .box-shadow-mixin(0, 2px, 10px, black); }
Comment
It looks like the mixin name is always getting added for nested children. Here's some test markup: .box-shadow-mixin (@h: 0, @v: 0, @blur: 0, @color: none) { box-shadow: @h @v @blur @color; -moz-box-shadow: @h @v @blur @color; -webkit-box-shadow: @h @v @blur @color; h1 { background-color: @color; } } .random-box { .box-shadow-mixin(0, 2px, 10px, black); }
or cancel
cloudhead Fri Nov 20 20:27:55 -0800 2009 | link

I had to reimplement dynamic mixins in a more robust way, to isolate them from external scope (circa 1.2.11), the problem with that is nesting won't work, so for now it'll throw a compile error, until I figure out a good way to implement this (and have the time to do so), which plays nicely with nesting.

Comment
I had to reimplement dynamic mixins in a more robust way, to isolate them from external scope (circa 1.2.11), the problem with that is nesting won't work, so for now it'll throw a compile error, until I figure out a good way to implement this (and have the time to do so), which plays nicely with nesting.
or cancel

xdissent Mon Nov 23 19:34:55 -0800 2009 | link

Good to know. I noticed recent activity and it's nice to see that this is part of what's being worked on! Thanks, dude.

Comment
Good to know. I noticed recent activity and it's nice to see that this is part of what's being worked on! Thanks, dude.
or cancel

Parsed with GitHub Flavored Markdown
108.

2 votes

enhancement
x

mixins - is the dot necessary?
0 comments Created about 1 month ago by jtousek

Title

Body
_item (@bg: none) { background-image: @bg; } .item1 { _item(url("/images/home/item1_background.png")); } I've tried to use something like this, but it cause a problem. Do the mixins with args need a dot on the begining? If yes, then why? It is not a class! Variables have @ but mixins nothing. And on the top, this is working: _test{ font-size: 12em; } h2 { _test; } Mixin with no dot on the begining but also no argument works fine, why that is not possible for mixins with aguments?
or cancel

item (@bg: none) { background-image: @bg; }
.item1 { item(url("/images/home/item1_background.png")); }

I've tried to use something like this, but it cause a problem. Do the mixins with args need a dot on the begining? If yes, then why? It is not a class! Variables have @ but mixins nothing. And on the top, this is working:

test{ font-size: 12em; }
h2 { test; }

Mixin with no dot on the begining but also no argument works fine, why that is not possible for mixins with aguments?

Comments

Parsed with GitHub Flavored Markdown
111.

0 votes

enhancement
x

Watch multiple files
0 comments Created about 1 month ago by j0hnsmith

Title

Body
It would be nice if less could watch multiple files lessc -w file1.less file2.less file3.less
or cancel
It would be nice if less could watch multiple files
```
lessc -w file1.less file2.less file3.less
```
Comments

Parsed with GitHub Flavored Markdown
113.

1 vote

enhancement
x

lessc execution speed very slow
3 comments Created 29 days ago by westonruter

Title

Body
I am attempting to compile a simple LESS file that @imports two additional simple CSS files. This is taking over 4 seconds! It seems that it should compile almost instantaneously. See also the following thread: "Lessc execution quite slow" http://groups.google.com/group/lesscss/browse_thread/thread/b9c0e10fe0278656/3301d1a420703fad
or cancel

I am attempting to compile a simple LESS file that @imports two additional simple CSS files. This is taking over 4 seconds! It seems that it should compile almost instantaneously. See also the following thread: "Lessc execution quite slow" http://groups.google.com/group/lesscss/browse_thread/thread/b9c0e10fe0278656/3301d1a420703fad

Comments

cloudhead Wed Nov 18 19:08:22 -0800 2009 | link

hmm, that's not normal — it takes 4 seconds to compile a 4000 sloc file on my machine. could you try running rake benchmark from the less folder? It shouldn't take more than 5-6 seconds.

Comment
hmm, that's not normal — it takes 4 seconds to compile a 4000 sloc file on my machine. could you try running `rake benchmark` from the less folder? It shouldn't take more than 5-6 seconds.
or cancel

miracle2k Wed Nov 18 21:15:19 -0800 2009 | link

We are using less in a Python website, have about 12 less files, and recompiling them all whenever there is a change takes up to 25 seconds. Not very nice to develop with.

I've hacked together a quick daemon mode which lets lessc take requests via a socket and send the compiled file back, so it needs to be run only once - this brings us down to 4 seconds.

The code is here: http://github.com/miracle2k/less It's not in any way something ready to be merged, but something along those lines could be considered for mainline.

Comment
We are using less in a Python website, have about 12 less files, and recompiling them all whenever there is a change takes up to 25 seconds. Not very nice to develop with. I've hacked together a quick daemon mode which lets lessc take requests via a socket and send the compiled file back, so it needs to be run only once - this brings us down to 4 seconds. The code is here: http://github.com/miracle2k/less It's not in any way something ready to be merged, but something along those lines could be considered for mainline.
or cancel

cloudhead Wed Nov 18 21:31:19 -0800 2009 | link

There is definitely room for a lot of optimizations in the grammar. It's something I'd like to look into at some point. Treetop isn't the fastest parser (being a PEG parser written in ruby) — but I think, by carefully optimizing the grammar, I should be able to get it 2-3x faster.

Comment
There is definitely room for a lot of optimizations in the grammar. It's something I'd like to look into at some point. Treetop isn't the fastest parser (being a PEG parser written in ruby) — but I think, by carefully optimizing the grammar, I should be able to get it 2-3x faster.
or cancel

Parsed with GitHub Flavored Markdown
110.

0 votes

error-reporting
x

failure when closing } omitted for nested selector
0 comments Created about 1 month ago by j0hnsmith

Title

Body
I forgot to close a nested class, at the time I was using the -w option - I got a failure and had to restart less. p { margin: 10px; a { color: red; } a doesn't have a closing } here's the output * Watching for changes in portals-layout.less... Ctrl-C to abort. /Library/Ruby/Gems/1.8/gems/less-1.1.13/bin/../lib/ext.rb:11:in `failure_message': undefined method `chr' for nil:NilClass (NoMethodError) from /Library/Ruby/Gems/1.8/gems/less-1.1.13/bin/../lib/less/engine.rb:38:in `parse' from /Library/Ruby/Gems/1.8/gems/less-1.1.13/bin/../lib/less/engine.rb:46:in `to_css' from /Library/Ruby/Gems/1.8/gems/less-1.1.13/bin/../lib/less/command.rb:64:in `parse' from /Library/Ruby/Gems/1.8/gems/less-1.1.13/bin/../lib/less/command.rb:50:in `run!' from /Library/Ruby/Gems/1.8/gems/less-1.1.13/bin/../lib/less/command.rb:42:in `loop' from /Library/Ruby/Gems/1.8/gems/less-1.1.13/bin/../lib/less/command.rb:42:in `run!' from /Library/Ruby/Gems/1.8/gems/less-1.1.13/bin/lessc:86 from /usr/bin/lessc:19:in `load' from /usr/bin/lessc:19 : Change detected...
or cancel
I forgot to close a nested class, at the time I was using the -w option - I got a failure and had to restart less.
```
p {
    margin: 10px;

    a {
        color: red;
}
```
a doesn't have a closing }

here's the output
```
* Watching for changes in portals-layout.less... Ctrl-C to abort.
/Library/Ruby/Gems/1.8/gems/less-1.1.13/bin/../lib/ext.rb:11:in `failure_message': undefined method `chr' for nil:NilClass (NoMethodError)
from /Library/Ruby/Gems/1.8/gems/less-1.1.13/bin/../lib/less/engine.rb:38:in `parse'
from /Library/Ruby/Gems/1.8/gems/less-1.1.13/bin/../lib/less/engine.rb:46:in `to_css'
from /Library/Ruby/Gems/1.8/gems/less-1.1.13/bin/../lib/less/command.rb:64:in `parse'
from /Library/Ruby/Gems/1.8/gems/less-1.1.13/bin/../lib/less/command.rb:50:in `run!'
from /Library/Ruby/Gems/1.8/gems/less-1.1.13/bin/../lib/less/command.rb:42:in `loop'
from /Library/Ruby/Gems/1.8/gems/less-1.1.13/bin/../lib/less/command.rb:42:in `run!'
from /Library/Ruby/Gems/1.8/gems/less-1.1.13/bin/lessc:86
from /usr/bin/lessc:19:in `load'
from /usr/bin/lessc:19
: Change detected... 
```
Comments

Parsed with GitHub Flavored Markdown
112.

1 vote

enhancement
x

Option to perserve select comments (i.e. the WordPress style.css theme metadata)
1 comment Created about 1 month ago by westonruter

Title

Body
I can't seem to find a built-in way to preserve certain comments so that they'll be included in the output. This is vital for WordPress which stores theme metadata at the top of style.css. If I have a style.less which automatically gets compiled to style.css, the header comment block is lost, and the WordPress theme is broken.
or cancel

I can't seem to find a built-in way to preserve certain comments so that they'll be included in the output. This is vital for WordPress which stores theme metadata at the top of style.css. If I have a style.less which automatically gets compiled to style.css, the header comment block is lost, and the WordPress theme is broken.

Comments

westonruter Mon Nov 09 11:42:01 -0800 2009 | link

Here's a WordPress filter to get LESS to automatically rebuild a theme's .css files when their corresponding .less files change: http://gist.github.com/230197

Comment
Here's a WordPress filter to get LESS to automatically rebuild a theme's .css files when their corresponding .less files change: http://gist.github.com/230197
or cancel

Parsed with GitHub Flavored Markdown
81.

0 votes

enhancement
x

Feature Suggestion: use md5 to determine if a single less file has been changed to speed up imports
1 comment Created 3 months ago by sandstrom

Title

Body
In regards to lessc --watch. Since there may be a noticeable delay between saving a file and the processing completion, one way to speed this up would be to split the less into multiple files, use import and have the watching lessc do md5 hashes on files after importing, speeding up the sequential imports (as long as the lessc deamon is running) since non-modified files wouldn't need to be parsed again. Perhaps such as feature could speed up things a bit when developing and using --watch?
or cancel

In regards to lessc --watch.

Since there may be a noticeable delay between saving a file and the processing completion, one way to speed this up would be to split the less into multiple files, use import and have the watching lessc do md5 hashes on files after importing, speeding up the sequential imports (as long as the lessc deamon is running) since non-modified files wouldn't need to be parsed again.

Perhaps such as feature could speed up things a bit when developing and using --watch?

Comments

cloudhead Sun Sep 06 13:47:52 -0700 2009 | link

interesting idea! will look into it.

Comment
interesting idea! will look into it.
or cancel

Parsed with GitHub Flavored Markdown
4.

3 votes

future
x

Compression doesn't work correctly
5 comments Created 6 months ago by dmitryf

Title

Body
Compression broke the CSS. Will need more investigation to narrow down the issue, but have to throw it out here so you know.
or cancel

Compression broke the CSS.

Will need more investigation to narrow down the issue, but have to throw it out here so you know.

Comments

cloudhead Wed May 20 11:27:11 -0700 2009 | link

Oh, now that I think of it, it'll break stuff like "solid 1px black", I have to come up with a comrpession algorithm or something.

Comment
Oh, now that I think of it, it'll break stuff like "solid 1px black", I have to come up with a comrpession algorithm or something.
or cancel

dmitryf Mon May 25 06:43:47 -0700 2009 | link

May be a good idea to have a look at other open source CSS compressors to see how they do it? Maybe just use the code from one? Don't know if there's any in Ruby.

Going back to thinking about the feature set of LESS -- do we need a compressor? I'm leaning on the side of "yes" because of this: with LESS you don't actually touch the CSS code, so if you don't touch the CSS there is no reason to waste space keeping it more organized for human readers. I think there should be a system to import multiple LESS files into one (sort of like @import, like sass also has) and then the output will be one big compressed CSS file from the one compile. That to me seems like the optimal setup for the developer working with LESS. Maybe they don't even need multiple LESS files, given that LESS saves a lot of duplication. Actually, that's one nice way of describing LESS -- it makes CSS DRY :)

Comment
May be a good idea to have a look at other open source CSS compressors to see how they do it? Maybe just use the code from one? Don't know if there's any in Ruby. Going back to thinking about the feature set of LESS -- do we need a compressor? I'm leaning on the side of "yes" because of this: with LESS you don't actually touch the CSS code, so if you don't touch the CSS there is no reason to waste space keeping it more organized for human readers. I think there should be a system to import multiple LESS files into one (sort of like @import, like sass also has) and then the output will be one big compressed CSS file from the one compile. That to me seems like the optimal setup for the developer working with LESS. Maybe they don't even need multiple LESS files, given that LESS saves a lot of duplication. Actually, that's one nice way of describing LESS -- it makes CSS DRY :)
or cancel

dmitryf Mon May 25 07:01:13 -0700 2009 | link

P.S. I must also note that while I said above that LESS should probably come with compression, it's not a feature that yields high gains. Uncompressed CSS won't break your project. Most people won't even care unless they're getting 100k visitors a day and they really need to minimize the file sizes. I think LESS should have it, but there are some other fixes to be made that will yield much bigger benefits, meaning this particular feature should not be high on the list of priorities.

Comment
P.S. I must also note that while I said above that LESS should probably come with compression, it's not a feature that yields high gains. Uncompressed CSS won't break your project. Most people won't even care unless they're getting 100k visitors a day and they really need to minimize the file sizes. I think LESS should have it, but there are some other fixes to be made that will yield much bigger benefits, meaning this particular feature should not be high on the list of priorities.
or cancel

cloudhead Mon May 25 08:39:00 -0700 2009 | link

agreed, I'm leaving it for the next version

Comment
agreed, I'm leaving it for the next version
or cancel

slowernet Mon Jun 22 13:53:43 -0700 2009 | link

IMHO: strip comments and whitespace, don't mess with compression. Leave it to the web server.

Comment
IMHO: strip comments and whitespace, don't mess with compression. Leave it to the web server.
or cancel

Parsed with GitHub Flavored Markdown
72.

0 votes

future
x

Syntax error on files in UTF-8 BOM
0 comments Created 4 months ago by ah01

Title

Body
Run lessc on UTF-8 BOM file cause this error: ! Syntax Error: on line 1: expected one of * - @ :: : . # [ @media @font-face @import /* // got ´ after:
or cancel
Run lessc on UTF-8 BOM file cause this error:
```
! Syntax Error: on line 1: expected one of * - @ :: : . # [ @media @font-face @import /* // got ´ after:
```
Comments

Parsed with GitHub Flavored Markdown
99.

1 vote

IE support
x

MS expressions
0 comments Created about 1 month ago by daz4126

Title

Body
LESS chokes on any of the propriety MS expressions at the moment, but this one would be useful for setting a max-width {width:expression(documentElement.clientWidth > @max-width-1 ? "@max-width" : "90%");}
or cancel

LESS chokes on any of the propriety MS expressions at the moment, but this one would be useful for setting a max-width

{width:expression(documentElement.clientWidth > @max-width-1 ? "@max-width" : "90%");}

Comments

Parsed with GitHub Flavored Markdown
85.

2 votes

IE support
x

Less chokes on some IE expressions (in Lightview's CSS)
1 comment Created 2 months ago by canavese

Title

Body
I'm using Nick Stakenburg's popular Lightview JS/CSS library (http://www.nickstakenburg.com/projects/lightview/) and can't include it using LESS. It chokes on a number of IE expressions: * html body #lightviewController { /* IE6 */ position: absolute; top: auto; margin-top: expression( (-1 * this.offsetHeight / 2 + (document.documentElement ? document.documentElement.scrollTop : 0) + (Lightview.controllerOffset || 0)) + 'px'); } * html #lightview { /* IE6 */ position: absolute; margin-top: expression( (-1 * this.offsetHeight / 2 + (document.documentElement ? document.documentElement.scrollTop : 0) - (Lightview.controllerHeight || 0)) + 'px'); margin-left: expression( -1 * this.offsetWidth / 2 + (document.documentElement ? document.documentElement.scrollLeft : 0) + 'px'); } /* Always cover 100% of the screen in IE6 */ html #lv_overlay { position: absolute; height: expression(((window.Enumerable && window.Enumerable.max) ? [document.body.scrollHeight, document.documentElement.scrollHeight, document.body.offsetHeight, document.documentElement.clientHeight].max() : document.documentElement.scrollHeight) + 'px' ); width: expression(((window.Enumerable && window.Enumerable.max) ? [document.body.scrollWidth, document.documentElement.scrollWidth, document.body.offsetWidth, document.documentElement.clientHeight].max() : document.documentElement.scrollWidth) + 'px' ); }
or cancel
I'm using Nick Stakenburg's popular Lightview JS/CSS library (http://www.nickstakenburg.com/projects/lightview/) and can't include it using LESS. It chokes on a number of IE expressions:
- html body #lightviewController { / IE6 / position: absolute; top: auto; margin-top: expression( (-1 * this.offsetHeight / 2 + (document.documentElement ? document.documentElement.scrollTop : 0) + (Lightview.controllerOffset || 0)) + 'px'); }
- html #lightview { / IE6 / position: absolute; margin-top: expression( (-1 this.offsetHeight / 2 + (document.documentElement ? document.documentElement.scrollTop : 0) - (Lightview.controllerHeight || 0)) + 'px'); margin-left: expression( -1 this.offsetWidth / 2 + (document.documentElement ? document.documentElement.scrollLeft : 0) + 'px'); }
/ Always cover 100% of the screen in IE6 / html #lv_overlay {
```
position: absolute;
height: expression(((window.Enumerable && window.Enumerable.max) ? [document.body.scrollHeight, document.documentElement.scrollHeight, document.body.offsetHeight, document.documentElement.clientHeight].max() : document.documentElement.scrollHeight) + 'px' );
width: expression(((window.Enumerable && window.Enumerable.max) ? [document.body.scrollWidth, document.documentElement.scrollWidth, document.body.offsetWidth, document.documentElement.clientHeight].max() : document.documentElement.scrollWidth) + 'px' );
```
}
Comments
canavese Sun Sep 13 21:34:58 -0700 2009 | link
Sorry for the poor formatting. Trying again:

* html body #lightviewController { /* IE6 */ position: absolute; top: auto; margin-top: expression( (-1 * this.offsetHeight / 2 + (document.documentElement ? document.documentElement.scrollTop : 0) + (Lightview.controllerOffset || 0)) + 'px'); } * html #lightview { /* IE6 */ position: absolute; margin-top: expression( (-1 * this.offsetHeight / 2 + (document.documentElement ? document.documentElement.scrollTop : 0) - (Lightview.controllerHeight || 0)) + 'px'); margin-left: expression( -1 * this.offsetWidth / 2 + (document.documentElement ? document.documentElement.scrollLeft : 0) + 'px'); } /* Always cover 100% of the screen in IE6 */ html #lv_overlay { position: absolute; height: expression(((window.Enumerable && window.Enumerable.max) ? [document.body.scrollHeight, document.documentElement.scrollHeight, document.body.offsetHeight, document.documentElement.clientHeight].max() : document.documentElement.scrollHeight) + 'px' ); width: expression(((window.Enumerable && window.Enumerable.max) ? [document.body.scrollWidth, document.documentElement.scrollWidth, document.body.offsetWidth, document.documentElement.clientHeight].max() : document.documentElement.scrollWidth) + 'px' ); }
Comment
Sorry for the poor formatting. Trying again: * html body #lightviewController { /* IE6 */ position: absolute; top: auto; margin-top: expression( (-1 * this.offsetHeight / 2 + (document.documentElement ? document.documentElement.scrollTop : 0) + (Lightview.controllerOffset || 0)) + 'px'); } * html #lightview { /* IE6 */ position: absolute; margin-top: expression( (-1 * this.offsetHeight / 2 + (document.documentElement ? document.documentElement.scrollTop : 0) - (Lightview.controllerHeight || 0)) + 'px'); margin-left: expression( -1 * this.offsetWidth / 2 + (document.documentElement ? document.documentElement.scrollLeft : 0) + 'px'); } /* Always cover 100% of the screen in IE6 */ html #lv_overlay { position: absolute; height: expression(((window.Enumerable && window.Enumerable.max) ? [document.body.scrollHeight, document.documentElement.scrollHeight, document.body.offsetHeight, document.documentElement.clientHeight].max() : document.documentElement.scrollHeight) + 'px' ); width: expression(((window.Enumerable && window.Enumerable.max) ? [document.body.scrollWidth, document.documentElement.scrollWidth, document.body.offsetWidth, document.documentElement.clientHeight].max() : document.documentElement.scrollWidth) + 'px' ); }
or cancel
Parsed with GitHub Flavored Markdown
31.

2 votes

low priority
x

pending
x

Can't parse IDs with colons
2 comments Created 5 months ago by jeremyh

Title

Body
Apps written using Java's JSF are littered with HTML elements with colons in the ID, eg: <input type="text" class="text" id="agreementForm:price:priceField1"/> To select these with CSS you can backslash the colon, like this: agreementForm\:price\:priceField1 { ... } ... But it doesn't work in IE. So you have to escape the colon as a hex code: agreementForm\3a price\3a priceField1 { ... } This works in all browsers, however Less doesn't recognise this syntax.
or cancel
Apps written using Java's JSF are littered with HTML elements with colons in the ID, eg:
```
<input type="text" class="text" id="agreementForm:price:priceField1"/>
```
To select these with CSS you can backslash the colon, like this:
```
agreementForm\:price\:priceField1 { ... }
```
... But it doesn't work in IE. So you have to escape the colon as a hex code:
```
agreementForm\3a price\3a priceField1 { ... }
```
This works in all browsers, however Less doesn't recognise this syntax.
Comments

jeremyh Tue Jul 07 20:57:18 -0700 2009 | link

I just noticed you commited a large rewrite to master an hour ago. I haven't tested this with the new version yet.

Comment
I just noticed you commited a large rewrite to master an hour ago. I haven't tested this with the new version yet.
or cancel

cloudhead Thu Jul 09 00:35:29 -0700 2009 | link

yea, I rewrote less from the ground-up using the treetop parsing library. This is definitely not going to work with the current code base though.

Comment
yea, I rewrote less from the ground-up using the treetop parsing library. This is definitely not going to work with the current code base though.
or cancel

Parsed with GitHub Flavored Markdown
68.

1 vote

css support
x

low priority
x

@-webkit-keyframes declaration causes syntax error
5 comments Created 4 months ago by nerkles

Title

Body
Admittedly this is not standard CSS (yet?) but it would be nice to have it not throw a syntax. Docs at: <http://developer.apple.com/documentation/AppleApplications/Reference/SafariCSSRef/Articles/OtherStandardCSS3Features.html#//apple_ref/doc/uid/TP40007601-SW4> example: @-webkit-keyframes 'tvout' { 0% { -webkit-transform: scale(1); } 10% { -webkit-transform: scale(1.2); } 40% { -webkit-transform: scale(0.1); } 100% { -webkit-transform: scale(0.01) } }
or cancel
Admittedly this is not standard CSS (yet?) but it would be nice to have it not throw a syntax.

Docs at: http://developer.apple.com/documentation/AppleApplications/Reference/SafariCSSRef/Articles/OtherStandardCSS3Features.html#//apple_ref/doc/uid/TP40007601-SW4

example:
```
@-webkit-keyframes 'tvout' {
0% {
    -webkit-transform: scale(1);
}
10% {
    -webkit-transform: scale(1.2);
}
40% {
    -webkit-transform: scale(0.1);
}
100% {
    -webkit-transform: scale(0.01)
}
}
```
Comments
revyver Sat Sep 12 13:18:32 -0700 2009 | link

In my "brief" experience, any -webkit-* based rule throws a syntax error. I've been having trouble with -webkit-transition in particular.

Comment
In my "brief" experience, any -webkit-* based rule throws a syntax error. I've been having trouble with -webkit-transition in particular.
or cancel

augustl Mon Sep 14 07:06:02 -0700 2009 | link

It should pass through anything it doesn't understand when it comes to declarations, but @-webkit-keyframes is a bit over the top. It makes sense to have a rule that passes through anything at any level it doesn't understand, though. +1 :)

Comment
It should pass through anything it doesn't understand when it comes to declarations, but `@-webkit-keyframes` is a bit over the top. It makes sense to have a rule that passes through anything at any level it doesn't understand, though. +1 :)
or cancel
cloudhead Mon Sep 14 11:25:11 -0700 2009 | link
yea that stuff is just crazy, I'm working on a CSS interpolation rule, which looks like

% { ...anything in here is skipped, and outputted as-is... }
Comment
yea that stuff is just crazy, I'm working on a CSS interpolation rule, which looks like % { ...anything in here is skipped, and outputted as-is... }
or cancel
nerkles Tue Sep 15 12:22:27 -0700 2009 | link

I like the idea that anything which does not need to be processed should pass through unharmed.

AFAIK, CSS Animation is a proposed standard, pretty darn awesome, and a potential accessible replacement for Flash (esp. combined w/SVG), and likely to be approved by W3C eventually.

Comment
I like the idea that anything which does not need to be processed should pass through unharmed. AFAIK, CSS Animation is a proposed standard, pretty darn awesome, and a potential accessible replacement for Flash (esp. combined w/SVG), and likely to be approved by W3C eventually.
or cancel

samsoffes Mon Nov 23 12:24:34 -0800 2009 | link

The % { } syntax would be great until support for all of the craziness is resolved.

Comment
The `% { }` syntax would be great until support for all of the craziness is resolved.
or cancel

Parsed with GitHub Flavored Markdown
119.

0 votes

enhancement
x

growl & syntax errors etc
3 comments Created 16 days ago by j0hnsmith

Title

Body
I would be nice if using lessc -gw ... or any combination of watch and growl, that you didn't have to Press [return] to continue... when there's a syntax error as growl already notifies the user. This way you could just fix the error and continue.
or cancel
I would be nice if using
```
lessc -gw ...
```
or any combination of watch and growl, that you didn't have to Press [return] to continue... when there's a syntax error as growl already notifies the user. This way you could just fix the error and continue.
Comments

guns Mon Nov 23 00:03:27 -0800 2009 | link

I agree that just fixing the error and resaving is more convenient than having to press return. I logged a similar issue here:

http://github.com/cloudhead/less/issues/#issue/116

and a proposed fix here:

http://github.com/guns/less/tree/guns-robust-watch

Comment
I agree that just fixing the error and resaving is more convenient than having to press `return`. I logged a similar issue here: <http://github.com/cloudhead/less/issues/#issue/116> and a proposed fix here: <http://github.com/guns/less/tree/guns-robust-watch>
or cancel

cloudhead Mon Nov 23 07:16:40 -0800 2009 | link

I was thinking about this too earlier, will see what I can do! (also going to merge in your patch at some point gun)

Comment
I was thinking about this too earlier, will see what I can do! (also going to merge in your patch at some point gun)
or cancel

Douwe Mon Nov 30 10:52:32 -0800 2009 | link

This would be nice also because it notifies you when a file that's being --watched has been compiled again. Currently, I don't know for sure if it has been compiled since the last time, as I'm not looking at my terminal all the time, to notice the extra line that appears... I just wait a couple of seconds to see if a new line pops up, and if it doesn't, I suppose it already popped up before I started looking.

Comment
This would be nice also because it notifies you when a file that's being `--watch`ed has been compiled again. Currently, I don't know for sure if it has been compiled since the last time, as I'm not looking at my terminal all the time, to notice the extra line that appears... I just wait a couple of seconds to see if a new line pops up, and if it doesn't, I suppose it already popped up before I started looking.
or cancel

Parsed with GitHub Flavored Markdown
121.

0 votes

IE support
x

Filter Syntax Error
1 comment Created 16 days ago by samsoffes

Title

Body
If you try to add the following code to a selector, a parse error will result: filter: progid:DXImageTransform.Microsoft.gradient(enabled='true', startColorstr=@top-color, endColorstr=@bottom-color, GradientType=1); > on line 30: expected one of , ; } got ' after: A lot of the `filter` values contain colons and other weird characters (thanks Microsoft). Escaping them would be acceptable, but it would obviously be preferred if Less just handled this correctly.
or cancel
If you try to add the following code to a selector, a parse error will result:
```
filter: progid:DXImageTransform.Microsoft.gradient(enabled='true', startColorstr=@top-color, endColorstr=@bottom-color, GradientType=1);
```
on line 30: expected one of , ; } got ' after:

A lot of the filter values contain colons and other weird characters (thanks Microsoft). Escaping them would be acceptable, but it would obviously be preferred if Less just handled this correctly.
Comments

jtousek Mon Nov 23 22:28:46 -0800 2009 | link

yeah this would be very useful - the syntax %{ ...returned as it is... } maight be good enough for this

Comment
yeah this would be very useful - the syntax %{ ...returned as it is... } maight be good enough for this
or cancel

Parsed with GitHub Flavored Markdown
123.

0 votes

Another strange error with data URLs: + changed to space
0 comments Created 10 days ago by mcvsama

Title

Body
Less code: .abc { background: url('data:image/png;base64,w8P+ivf') repeat-x scroll 0 0; } compiles to: .abc { background: url('data:image/png;base64,w8P ivf') repeat-x scroll 0 0; } which breaks MIME encoding. Adding '' or "" doesn't help. Less version: 1.2.17, Ruby: 1.8.7.
or cancel

Less code:

.abc { background: url('data:image/png;base64,w8P+ivf') repeat-x scroll 0 0; }

compiles to:

.abc { background: url('data:image/png;base64,w8P ivf') repeat-x scroll 0 0; }

which breaks MIME encoding. Adding '' or "" doesn't help.

Less version: 1.2.17, Ruby: 1.8.7.

Comments

Parsed with GitHub Flavored Markdown
124.

0 votes

Reference to parent selector
11 comments Created 10 days ago by Douwe

Title

Body
Is there any way to reference to the parent selector? To do something like this: a.button { height: 20px; width: 100px; background-repeat: no-repeat; &.email { background-image: url(email.png); } &.twitter { background-image: url(twitter.png); } } As you can see, I am using the & character to reference to the parent selector. My goal is to apply the specified `background-image`s to `a.button.email` and `a.button.twitter`, without having to write `a.button` again, when I'm already in the `a.button` block.
or cancel
Is there any way to reference to the parent selector? To do something like this:
```
a.button {
  height: 20px;
  width: 100px;
  background-repeat: no-repeat;

  &.email {
    background-image: url(email.png);
  }
  &.twitter {
    background-image: url(twitter.png);
  }
}
```
As you can see, I am using the & character to reference to the parent selector.
My goal is to apply the specified background-images to a.button.email and a.button.twitter, without having to write a.button again, when I'm already in the a.button block.
Comments
jtousek Mon Nov 30 08:36:04 -0800 2009 | link

not yet, see http://github.com/cloudhead/less/issues/#issue/109

Comment
not yet, see http://github.com/cloudhead/less/issues/#issue/109
or cancel
xdissent Mon Nov 30 09:11:38 -0800 2009 | link
Do you mean to accomplish the following?

a.button { height: 20px; width: 100px; background-repeat: no-repeat; } a.email { background-image: url(email.png) } a.twitter { background-image: url(twitter.png) }

Are you trying to use the parent selector to discriminate against as that don't have the button class? If it's not likely that any a tag will have the email or twitter classes and not the button class, this will work as expected.
Comment
Do you mean to accomplish the following? a.button { height: 20px; width: 100px; background-repeat: no-repeat; } a.email { background-image: url(email.png) } a.twitter { background-image: url(twitter.png) } Are you trying to use the parent selector to discriminate against `a`s that *don't* have the `button` class? If it's not likely that any `a` tag will have the `email` or `twitter` classes and *not* the `button` class, this will work as expected.
or cancel
jtousek Mon Nov 30 09:13:49 -0800 2009 | link
more likely

a.button { height: 20px; width: 100px; background-repeat: no-repeat; } a.button.email { background-image: url(email.png) } a.button.twitter { background-image: url(twitter.png) }
Comment
more likely <pre> a.button { height: 20px; width: 100px; background-repeat: no-repeat; } a.button.email { background-image: url(email.png) } a.button.twitter { background-image: url(twitter.png) } </pre>
or cancel
xdissent Mon Nov 30 09:52:32 -0800 2009 | link

Wow, I had completely forgotten about chaining class names. You're right, that's far more accurate.

So I guess we need a more compelling use case for this feature, right?

Comment
Wow, I had completely forgotten about chaining class names. You're right, that's far more accurate. So I guess we need a more compelling use case for this feature, right?
or cancel

Douwe Mon Nov 30 09:52:53 -0800 2009 | link

What jtousek says.
I want the & character (or any other special char) to reference to the parent selector, just like pseudo-classes like :hover do by default.

Comment
What jtousek says. I want the `&` character (or any other special char) to reference to the parent selector, just like pseudo-classes like `:hover` do by default.
or cancel

jtousek Mon Nov 30 10:19:05 -0800 2009 | link

xdissent:
you mean something like this? (it convinced cloudhead)
http://github.com/cloudhead/less/issues/#issue/109/comment/77628

Comment
xdissent: you mean something like this? (it convinced cloudhead) http://github.com/cloudhead/less/issues/#issue/109/comment/77628
or cancel
xdissent Mon Nov 30 10:25:08 -0800 2009 | link
Exactly! Sheesh, I'm behind the times. But for clarification, in Douwe's case, chaining classnames with a period will suffice. Like this:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <title>OMGWOW</title> <style type="text/css"> a { background-color: #f00; /* Red */ } a.email { background-color: #0f0; /* Green */ } a.twitter { background-color: #00f; /* Blue */ } a.button { background-color: #ff0; /* Yellow */ border: 1px solid <a href="/cloudhead/less/issues/#issue/0" class="internal">#0</a>; } a.button.email { background-color: #0ff; /* Cyan */ } a.button.twitter { background-color: #f0f; /* Magenta */ } </style> </head> <body> <p><a href="http://example.com">Link</a></p> <p><a class="email" href="mailto:test@example.com">Email link</a></p> <p><a class="twitter" href="http://twitter.com">Twitter link</a></p> <p><a class="button" href="http://example.com">Button</a></p> <p><a class="button email" href="mailto:test@example.com">Email button</a></p> <p><a class="button twitter" href="http://twitter.com">Twitter button</a></p> </body> </html>

Thanks though, I do see how this feature could be very useful now. Maybe merge these issues?
Comment
Exactly! Sheesh, I'm behind the times. But for clarification, in Douwe's case, chaining classnames with a period will suffice. Like this: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <title>OMGWOW</title> <style type="text/css"> a { background-color: #f00; /* Red */ } a.email { background-color: #0f0; /* Green */ } a.twitter { background-color: #00f; /* Blue */ } a.button { background-color: #ff0; /* Yellow */ border: 1px solid #000; } a.button.email { background-color: #0ff; /* Cyan */ } a.button.twitter { background-color: #f0f; /* Magenta */ } </style> </head> <body> <p><a href="http://example.com">Link</a></p> <p><a class="email" href="mailto:test@example.com">Email link</a></p> <p><a class="twitter" href="http://twitter.com">Twitter link</a></p> <p><a class="button" href="http://example.com">Button</a></p> <p><a class="button email" href="mailto:test@example.com">Email button</a></p> <p><a class="button twitter" href="http://twitter.com">Twitter button</a></p> </body> </html> Thanks though, I do see how this feature could be very useful now. Maybe merge these issues?
or cancel
Douwe Mon Nov 30 10:28:47 -0800 2009 | link
Well, when LESS would implement some way to reference the parent selector, you could do that like this:

a.button { background-color: #ff0; /* Yellow */ border: 1px solid black; &.email { background-color: #0ff; /* Cyan */ } &.twitter { background-color: #f0f; /* Magenta */ } }

(Assume & is the special character)

Much cleaner in my opinion ;-)
Comment
Well, when LESS would implement some way to reference the parent selector, you could do that like this: a.button { background-color: #ff0; /* Yellow */ border: 1px solid black; &.email { background-color: #0ff; /* Cyan */ } &.twitter { background-color: #f0f; /* Magenta */ } } (Assume `&` is the special character) Much cleaner in my opinion ;-)
or cancel
xdissent Mon Nov 30 10:33:33 -0800 2009 | link

Right, but it's possible to accomplish right now, which is cool. I agree this should be implemented, though. It is nicer than the alternative, especially with long selectors.

Comment
Right, but it's *possible* to accomplish right now, which is cool. I agree this should be implemented, though. It is nicer than the alternative, especially with long selectors.
or cancel

Douwe Mon Nov 30 10:34:52 -0800 2009 | link

Yeah, of course it's possible, everything you can do in LESS is possible in CSS, it's just way easier / cooler / cleaner ;-)

Comment
Yeah, of course it's possible, everything you can do in LESS is possible in CSS, it's just way easier / cooler / cleaner ;-)
or cancel

xdissent Mon Nov 30 10:37:37 -0800 2009 | link

Technically true. =)

Comment
*Technically* true. =)
or cancel

Parsed with GitHub Flavored Markdown
125.

0 votes

Can't parse print CSS
1 comment Created 2 days ago by jeremyh

Title

Body
I get a parse errror using less 1.2.19 with print CSS selectors: @page { margin: 2cm } @page :first { margin-top: 10cm } The CSS paged media specification: http://www.w3.org/TR/css3-page/
or cancel
I get a parse errror using less 1.2.19 with print CSS selectors:
```
@page { margin: 2cm } 

@page :first {
  margin-top: 10cm 
}
```
The CSS paged media specification: http://www.w3.org/TR/css3-page/
Comments

jtousek Tue Dec 08 14:01:26 -0800 2009 | link

well i guess that's just about units - shouldn't be hard to fix

Comment
well i guess that's just about units - shouldn't be hard to fix
or cancel

Parsed with GitHub Flavored Markdown