less.ruby
less.ruby copied to clipboard
less
Class selectors in nested rules
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?
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.
.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.
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.
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.
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 {...}
well I really don't like backtick (`), I'd prefere $ or \ or &... about pseoudo-classes and pseudo-elements I agree
great :)
what about <? As a kind of opposite of the direct ancestor concatenator. But I don't mind if it is the backtick.
I'm still against backtick. :) But I'm ok with < idea (of course $ is prefered). Let's wait for cloudhead's opinion.
&.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
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. ;)
Ampersand. For serious. Please. With a cherry on top. I'm confused enough as it is switching back and forth between SASS and LESS.
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)
I vote for & or $. & would be nice because it's like in SASS, and $ would rock, just because it's $.
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.
< feels the most intuitive for referencing the parent element. For people familiar with CSS and unfamiliar with LESS, they're going to think of < as the opposite of the child selector.
I vote for &, as it functions more as a this or self selector than a parent selector... So < wouldn't actually be the opposite of the > selector.
& it is!
The thing to remember is .a { &.b {...} } is the same as .b { &.a {...} } so it's more of an 'append' than simply a reference to the parent selector. I liked the backticks, but they aren't that obvious, and should probably be kept for quoting things.
Yeah, but .a { ... &.b { ... } } isn't the same as .b { ... &.a { ... } } ;-) But I get what you mean :-)
(Will .a { &:hover { ... } } also be available next to the original .a { :hover { ... } }?)
Yea, &:hover should behave the same as :hover. If you want the equivalent of a :hover, you can use *:hover
great! :) btw. cloudhead, is there some kind of change log? there are lot of issues reported here but I don't know what is already implemented/fixed and what is still waiting...
@Douwe: I haven't implemented this yet, no : )
@jtousek: if the issue is still open here, then it's not fixed/implemented. The most accurate changelog would probably be the commit history, although that can be hard to follow — I don't really have the patience/time to maintain a separate one...
Just signed up to thank you for your fantastic work... and to note that this missing feature is what prevents me from using less :(
Well what prevents me from using less is this thing along with "filter: ..." incompatibility... I'm looking forward for finishing these issues.