Less.js - strong nested rules?
It's as simple as this:
.A {
> .B {
width: 50px;
}
}
Another related question: Immediate Child selector in LESS
Some documentation: http://lesscss.org/features/#features-overview-feature-nested-rules
(doesn't actually include relevant example)
Immediate Child selector in LESS
UPDATE
Actually, the code in the original question works fine. You can just stick with the > child selector.
Found the answer.
.panel {
...
>.control {
...
}
}
Note the lack of space between ">" and ".", otherwise it won't work.
Ampersand in Less.js vs. SCSS
I don't think you can do the body.admin & thing with LESS. Probably not a bad thing, because it's confusing.
For > (child selector), see: Less.js - strong nested rules?
See: http://tinkerbin.com/H3wUpFMj (change the CSS format to "Less", then press "Run")
It's as simple as this:
.A {
> .B {
width: 50px;
}
}
LESS CSS: abusing the & Operator when nesting?
I also have been pondering this use further since we encountered it in that question you referenced. While I cannot answer definitively that this is a "bug" use for & (BoltClock seems to make a good argument that it is not a bug), I want to argue for the value of it (which argues it is not a bug from a logical standpoint).
However, before the logical argument, I did find another short, simple quote (in the "nested rules" section) that seems to indicate it is at least not unintended: "& represents the current selector parent." That's it. As BoltClock argues, whether prepending or appending seems irrelevant. All that was intended was that it be a placeholder for that "selector parent" that is current up to that point. The fact that it is always mentioned in conjunction with the "nesting" use of the language implies it is designed to designate the full selector string of the nest up to the point of the nest that it resides within. How that string is used (to pre- or append) would seem up to the coder.
Now, you mention (and previously mentioned) that you "would never code this way," and yet I find myself seeing what appears to be a very valuable use for this. Consider the following argument.
The HTML Setup for the Illustration
Assume, for the sake of illustration, there is a dynamic setting of three possible classes ('light', 'medium', 'dark' themes) on the body element that change the "look" of the site. We have
two columns, and some various types of links we want to style (textLink, picLink, textWithIconLink) differently in each column for each theme.
<body class="light">
<div class="leftCol">
<a class="textLink"></a>
<a class="picLink"></a>
<a class="textWithIconLink"></a>
</div>
<div class="rightCol">
<a class="textLink"></a>
<a class="picLink"></a>
<a class="textWithIconLink"></a>
</div>
</body>
Now the questions to ask are, just looking at the links, of the two following methods, which...
- Is less code in LESS
- Best organzies the code in LESS
- Outputs less code in CSS
- Best organizes the outputted CSS
"Best" may be somewhat subjective. I'll let you weigh that evidence yourself from below.
Option #1 Typical Nesting
LESS (approx. 99 lines of code)
/*Light Color Theme */
.light {
.leftCol {
.textLink {
color: fooL1;
&:hover { color: barL1;}
}
.picLink {
background-image: url(/fooL1.jpg);
&:hover { background-image: url(/barL1.jpg);}
}
.textWithIconLink {
color: fooL2;
background-image: url(/fooL2.jpg);
&:hover { color: barL2; background-image: url(/barL2.jpg);}
}
}
.rightCol {
.textLink {
color: fooL3;
&:hover { color: barL3;}
}
.picLink {
background-image: url(/fooL3.jpg);
&:hover { background-image: url(/barL3.jpg);}
}
.textWithIconLink {
color: fooL4;
background-image: url(/fooL4.jpg);
&:hover { color: barL4; background-image: url(/barL4.jpg);}
}
}
}
/*Medium Color Theme */
.medium {
.leftCol {
.textLink {
color: fooM1;
&:hover { color: barM1;}
}
.picLink {
background-image: url(/fooM1.jpg);
&:hover { background-image: url(/barM1.jpg);}
}
.textWithIconLink {
color: fooM2;
background-image: url(/fooM2.jpg);
&:hover { color: barM2; background-image: url(/barM2.jpg);}
}
}
.rightCol {
.textLink {
color: fooM3;
&:hover { color: barM3;}
}
.picLink {
background-image: url(/fooM3.jpg);
&:hover { background-image: url(/barM3.jpg);}
}
.textWithIconLink {
color: fooM4;
background-image: url(/fooM4.jpg);
&:hover { color: barM4; background-image: url(/barM4.jpg);}
}
}
}
/*Dark Color Theme */
.dark {
.leftCol {
.textLink {
color: fooD1;
&:hover { color: barD1;}
}
.picLink {
background-image: url(/fooD1.jpg);
&:hover { background-image: url(/barD1.jpg);}
}
.textWithIconLink {
color: fooD2;
background-image: url(/fooD2.jpg);
&:hover { color: barD2; background-image: url(/barD2.jpg);}
}
}
.rightCol {
.textLink {
color: fooD3;
&:hover { color: barD3;}
}
.picLink {
background-image: url(/fooD3.jpg);
&:hover { background-image: url(/barD3.jpg);}
}
.textWithIconLink {
color: fooD4;
background-image: url(/fooD4.jpg);
&:hover { color: barD4; background-image: url(/barD4.jpg);}
}
}
}
CSS Output (approx. 87 lines of output, organized by theme of course)
/*Light Color Theme */
.light .leftCol .textLink { color:fooL1; }
.light .leftCol .textLink:hover { color:barL1; }
.light .leftCol .picLink { background-image:url(/fooL1.jpg); }
.light .leftCol .picLink:hover { background-image:url(/barL1.jpg); }
.light .leftCol .textWithIconLink {
color:fooL2;
background-image:url(/fooL2.jpg);
}
.light .leftCol .textWithIconLink:hover {
color:barL2;
background-image:url(/barL2.jpg);
}
.light .rightCol .textLink { color:fooL3; }
.light .rightCol .textLink:hover { color:barL3; }
.light .rightCol .picLink { background-image:url(/fooL3.jpg); }
.light .rightCol .picLink:hover { background-image:url(/barL3.jpg); }
.light .rightCol .textWithIconLink {
color:fooL4;
background-image:url(/fooL4.jpg);
}
.light .rightCol .textWithIconLink:hover {
color:barL4;
background-image:url(/barL4.jpg);
}
/*Medium Color Theme */
.medium .leftCol .textLink { color:fooM1; }
.medium .leftCol .textLink:hover { color:barM1; }
.medium .leftCol .picLink { background-image:url(/fooM1.jpg); }
.medium .leftCol .picLink:hover { background-image:url(/barM1.jpg); }
.medium .leftCol .textWithIconLink {
color:fooM2;
background-image:url(/fooM2.jpg);
}
.medium .leftCol .textWithIconLink:hover {
color:barM2;
background-image:url(/barM2.jpg);
}
.medium .rightCol .textLink { color:fooM3; }
.medium .rightCol .textLink:hover { color:barM3; }
.medium .rightCol .picLink { background-image:url(/fooM3.jpg); }
.medium .rightCol .picLink:hover { background-image:url(/barM3.jpg); }
.medium .rightCol .textWithIconLink {
color:fooM4;
background-image:url(/fooM4.jpg);
}
.medium .rightCol .textWithIconLink:hover {
color:barM4;
background-image:url(/barM4.jpg);
}
/*Dark Color Theme */
.dark .leftCol .textLink { color:fooD1; }
.dark .leftCol .textLink:hover { color:barD1; }
.dark .leftCol .picLink { background-image:url(/fooD1.jpg); }
.dark .leftCol .picLink:hover { background-image:url(/barD1.jpg); }
.dark .leftCol .textWithIconLink {
color:fooD2;
background-image:url(/fooD2.jpg);
}
.dark .leftCol .textWithIconLink:hover {
color:barD2;
background-image:url(/barD2.jpg);
}
.dark .rightCol .textLink { color:fooD3; }
.dark .rightCol .textLink:hover { color:barD3; }
.dark .rightCol .picLink { background-image:url(/fooD3.jpg); }
.dark .rightCol .picLink:hover { background-image:url(/barD3.jpg); }
.dark .rightCol .textWithIconLink {
color:fooD4;
background-image:url(/fooD4.jpg);
}
.dark .rightCol .textWithIconLink:hover {
color:barD4;
background-image:url(/barD4.jpg);
}
Option #2 End Target Grouping
I've named it "End Target Grouping," because that's really how I see using the & in this other way of adding parent selectors. One is now coding based off the final end target element that is actually being styled.
LESS (approx. 88 lines of code)
/*Links */
/*Text Links*/
.textLink {
.light .leftCol & {
color: fooL1;
&:hover { color: barL1;}
}
.light .rightCol & {
color: fooL3;
&:hover { color: barL3;}
}
.medium .leftCol & {
color: fooM1;
&:hover { color: barM1;}
}
.medium .rightCol & {
color: fooM3;
&:hover { color: barM3;}
}
.dark .leftCol & {
color: fooD1;
&:hover { color: barD1;}
}
.dark .rightCol & {
color: fooD3;
&:hover { color: barD3;}
}
}
/*Picture Links */
.picLink {
.light .leftCol & {
background-image: url(/fooL1.jpg);
&:hover { background-image: url(/barL1.jpg);}
}
.light .rightCol & {
background-image: url(/fooL3.jpg);
&:hover { background-image: url(/barL3.jpg);}
}
.medium .leftCol & {
background-image: url(/fooM1.jpg);
&:hover { background-image: url(/barM1.jpg);}
}
.medium .rightCol & {
background-image: url(/fooM3.jpg);
&:hover { background-image: url(/barM3.jpg);}
}
.dark .leftCol & {
background-image: url(/fooD1.jpg);
&:hover { background-image: url(/barD1.jpg);}
}
.dark .rightCol & {
background-image: url(/fooD3.jpg);
&:hover { background-image: url(/barD3.jpg);}
}
}
/*Text with Icon Links */
.textWithIconLink {
.light .leftCol & {
color: fooL2;
background-image: url(/fooL1.jpg);
&:hover { color: barL2; background-image: url(/barL1.jpg);}
}
.light .rightCol & {
color: fooL4;
background-image: url(/fooL3.jpg);
&:hover { color: barL4; background-image: url(/barL3.jpg);}
}
.medium .leftCol & {
color: fooM2;
background-image: url(/fooM1.jpg);
&:hover { color: barM2; background-image: url(/barM1.jpg);}
}
.medium .rightCol & {
color: fooM4;
background-image: url(/fooM3.jpg);
&:hover { color: barM4; background-image: url(/barM3.jpg);}
}
.dark .leftCol & {
color: fooD2;
background-image: url(/fooD1.jpg);
&:hover { color: barD2; background-image: url(/barD1.jpg);}
}
.dark .rightCol & {
color: fooD4;
background-image: url(/fooD3.jpg);
&:hover { color: barD4; background-image: url(/barD3.jpg);}
}
}
CSS (approx. 88 lines of output [due to one extra comment], organized by end target element; but notice, there is still a suborganization by theme because of the class structure)
/*Links*/
/*Text Links*/
.light .leftCol .textLink { color:fooL1; }
.light .leftCol .textLink:hover { color:barL1; }
.light .rightCol .textLink { color:fooL3; }
.light .rightCol .textLink:hover { color:barL3; }
.medium .leftCol .textLink { color:fooM1; }
.medium .leftCol .textLink:hover { color:barM1; }
.medium .rightCol .textLink { color:fooM3; }
.medium .rightCol .textLink:hover { color:barM3; }
.dark .leftCol .textLink { color:fooD1; }
.dark .leftCol .textLink:hover { color:barD1; }
.dark .rightCol .textLink { color:fooD3; }
.dark .rightCol .textLink:hover { color:barD3; }
/*Picture Links */
.light .leftCol .picLink { background-image:url(/fooL1.jpg); }
.light .leftCol .picLink:hover { background-image:url(/barL1.jpg); }
.light .rightCol .picLink { background-image:url(/fooL3.jpg); }
.light .rightCol .picLink:hover { background-image:url(/barL3.jpg); }
.medium .leftCol .picLink { background-image:url(/fooM1.jpg); }
.medium .leftCol .picLink:hover { background-image:url(/barM1.jpg); }
.medium .rightCol .picLink { background-image:url(/fooM3.jpg); }
.medium .rightCol .picLink:hover { background-image:url(/barM3.jpg); }
.dark .leftCol .picLink { background-image:url(/fooD1.jpg); }
.dark .leftCol .picLink:hover { background-image:url(/barD1.jpg); }
.dark .rightCol .picLink { background-image:url(/fooD3.jpg); }
.dark .rightCol .picLink:hover { background-image:url(/barD3.jpg); }
/*Text with Icon Links */
.light .leftCol .textWithIconLink {
color:fooL2;
background-image:url(/fooL1.jpg);
}
.light .leftCol .textWithIconLink:hover {
color:barL2;
background-image:url(/barL1.jpg);
}
.light .rightCol .textWithIconLink {
color:fooL4;
background-image:url(/fooL3.jpg);
}
.light .rightCol .textWithIconLink:hover {
color:barL4;
background-image:url(/barL3.jpg);
}
.medium .leftCol .textWithIconLink {
color:fooM2;
background-image:url(/fooM1.jpg);
}
.medium .leftCol .textWithIconLink:hover {
color:barM2;
background-image:url(/barM1.jpg);
}
.medium .rightCol .textWithIconLink {
color:fooM4;
background-image:url(/fooM3.jpg);
}
.medium .rightCol .textWithIconLink:hover {
color:barM4;
background-image:url(/barM3.jpg);
}
.dark .leftCol .textWithIconLink {
color:fooD2;
background-image:url(/fooD1.jpg);
}
.dark .leftCol .textWithIconLink:hover {
color:barD2;
background-image:url(/barD1.jpg);
}
.dark .rightCol .textWithIconLink {
color:fooD4;
background-image:url(/fooD3.jpg);
}
.dark .rightCol .textWithIconLink:hover {
color:barD4;
background-image:url(/barD3.jpg);
}
Concluding Thoughts
A few other considerations:
First, most of your theme colors (and possibly other themeing aspects) will be set up with variables, which can be grouped at the top of the LESS code by theme even using Option #2 above--so having the theme structure for the output CSS itself scattered in the code is not necessarily bad.
Second, any "standard" code for a type of element is defined above any theme code. My examples did not show this, but say all .textLink elements had text-decoration: none; set. That would occur once under Option #2 without any further selector code, and would appear above all the theme changes below. For Option #1, I need to set up a new, unnested .textLink selector (at least one other line of code) to apply it to all themed links, and that "base" code for the class will, again, be somewhere unrelated to where the rest of the code for the theme link info is.
Third, as a developer, if I am having issues with my picLinks (a specific type of element on my page), Option #2 makes it far easier to examine my code for the element I am having issues with, as all my code for all the themes is right in one spot.
Obviously, how one wants the final LESS and CSS organized is going to be a major factor in how one sees the value of this. My point here is to merely demonstrate that there is a very useful, logical reason to use the & in this way of adding parent level selectors to the & reference.
Does {} consume less memory than [] for nested objects in Javascript?
There is no such thing as an "associated array" in JavaScript. [ 1, 2, 3 ] is array literal syntax; it initializes an Array. { foo: "bar" } is object literal syntax; it initializes an Object. A quirk of JavaScript, however, is that Arrays also happen to be Objects, which is why this code "works":
var data = [];
data["first"] = [];
data["first"]["second"] = [];
...but you shouldn't do it, because it doesn't make any sense. You're initializing an empty Array ([]), but then you're not using it like an Array—you're using it like an Object. If you're using property names (data["first"], which is equivalent to data.first) instead of integer keys (data[0]), then you want to use an Object. There is no scenario in which you should initialize an Array when you're going to use it like an Object.
As a rule of thumb, if you need each item to have a name, or need to be able to access them quickly by a name, use an Object ({}) and use strings for keys. If you need to be able to iterate over the items in order, use an Array with integers for keys.
I don't know the exact cause of your out-of-memory error—especially not without seeing your actual code—but it is definitely the case that you should be using an Object ({}), not an Array ([]) when you're not using integer keys. JavaScript engines optimize everything they can, and Arrays and Objects are no exception, so it's not surprising that when you use an Array in a way that the engine doesn't expect it might cause performance or memory problems.
P.S. As a matter of style, consider using property notation (or "dot notation," i.e. foo.bar) instead of subscript notation (i.e. foo["bar"]) when dealing with Objects:
var data = {};
data.first = {};
data.first.second = {};
data.first.second2 = "hello";
This is exactly equivalent to the code you posted, but it's easier to read and might help you remember that Objects and Arrays have different uses. You could also just express this as a single object literal:
var data = {
first: {
second: {},
second2: "hello"
}
};
This is also exactly equivalent and helps you see the "structure" of your object (as long as you're disciplined about indentation).
Most JavaScript style guides say that you should always use "dot notation" unless you have keys that would cause a syntax error. For example, if you have a property named "foo/bar", you obviously can't do this:
var obj.foo/bar = 1;
...because it's a syntax error. So you have to do this:
var obj["foo/bar"] = 1;
...which is perfectly valid. These cases tend to be the exception, so I would encourage to always use dot notation unless you have to use subscript notation.
LESS: Variables that contains multiple selector for use inside another selector
See also: https://github.com/less/less.js/issues/2263
If you are enable to split @var into two (or more) separated variables you can use the following Less code:
@var1: ~"> a";
@var2: ~"> a:hover";
body > header {@{var1},@{var2} { > strong > em {color:red;}}}
The preceding will compile into the following CSS code:
body > header > a > strong > em,
body > header > a:hover > strong > em {
color: red;
}
When @var: "a", "a:hover"; you can also use:
@var1: e(extract(@var,1));
@var2: e(extract(@var,2));
body > header {
> @{var1}, > @{var2} {
> strong > em {
color: red;
}
}
}
Or use a complex mixin (as Bootstrap does, see: LESS loops used to generate column classes in twitter - How do they work?) to build your selectors:
.mixin(@iterator: 0; @selectors: ~""; @seperator: ~"") when (@iterator < length(@var)) {
@blah: ~"body > header > @{selector} > strong > em";
@selector: extract(@var,@iterator + 1);
@selectorlist: ~"@{selectors} @{seperator} @{blah}";
.mixin((@iterator + 1); @selectorlist; ~",");
}
.mixin(@iterator; @selectors: ~""; @seperator: ~"") when (@iterator = length(@var)) {
@{selectors} {
color:red;
}
}
.mixin();
Double ampersand in LESS
What happens when you use an ampersand in a nested rule is that the default nested structure gets ignored in the output selector and the ampersand acts as a placeholder for the complete list of outer selectors and will just insert all the parent rules all the way to the top of the hierarchy (the "path" for all nesting levels above) ... no way around that.
So using the first one - & will just join (concatenate) the nested selector to the whole list of outer selectors (appearing as if it just added it to the parent selector) and act as a combinator - see "Nested rules" at lescss.org. But then when you use the second ampersand - your selector will end up including all outer rules once again - the .wrapper and all rules in between will be added twice now. So, the behavior is not really strange. See also my answer to this question: "How to refer to two previous elements / tags / classes with LESS?" and for some more functionality of & see also seven-phases-max's comments below. Or find some examples of & being used as a "path" placeholder under "Advanced Usage of &" at lescss.org.
And to your concrete example:
I am not completely sure why you want to repeat the word "header" in the class name .header--type-small, if you are using it in addition to a class called .header ... I would just use additional classes such as .type-small, like so:
.wrapper {
//style for the wrapper
.heading{
//general style for the heading
&.type-small {
//style for the heading with class .type-small
font-size: 15px;
}
&.type-large {
//style for the heading with class .type-large ... and so on
}
}
}
with output CSS:
.wrapper .heading.type-small {
font-size: 15px;
}
but if you really really need the whole long string with the repeated names for some particular reason ... you could just do something like this:
.wrapper {
//style for the wrapper
.heading {
//general style for the heading
&.heading--type{
&-small {
//style for the heading with class .type-small
font-size: 15px;
}
}
}
}
with output CSS:
.wrapper .heading.heading--type-small {
font-size: 15px;
}
Nested mixins in LESS throws an error
A quick search led me to this bugreport. It is a known issue.
https://github.com/cloudhead/less.js/issues/740
To be honest I would suggest you try to accomplish what you're trying to do some other way. The less.js backlog is at time of this writing 417 issues large. It isn't likely going to be fixed any time soon.
(yes it is this bugreport, you created a nested rule by extending .foo with .bar)
Does LESS have an extend feature?
Yes, Less.js introduced extend in v1.4.0.
:extend()
Rather than implementing the at-rule (@extend) syntax used by SASS and Stylus, LESS implemented the pseudo-class syntax, which gives LESS's implementation the flexibility to be applied either directly to a selector itself, or inside a statement. So both of these will work:
.sidenav:extend(.nav) {...}
or
.sidenav {
&:extend(.nav);
...
}
Additionally, you can use the all directive to extend "nested" classes as well:
.sidenav:extend(.nav all){};
And you can add a comma-separated list of classes you wish to extend:
.global-nav {
&:extend(.navbar, .nav all, .navbar-fixed-top all, .navbar-inverse);
height: 70px;
}
When extending nested selectors you should notice the differences:
nested selectors .selector1 and selector2:
.selector1 {
property1: a;
.selector2 {
property2: b;
}
}
Now .selector3:extend(.selector1 .selector2){}; outputs:
.selector1 {
property1: a;
}
.selector1 .selector2,
.selector3 {
property2: b;
}
, .selector3:extend(.selector1 all){}; outputs:
.selector1,
.selector3 {
property1: a;
}
.selector1 .selector2,
.selector3 .selector2 {
property2: b;
}
,.selector3:extend(.selector2){}; outputs
.selector1 {
property1: a;
}
.selector1 .selector2 {
property2: b;
}
and finally .selector3:extend(.selector2 all){};:
.selector1 {
property1: a;
}
.selector1 .selector2,
.selector1 .selector3 {
property2: b;
}
Related Topics
Distorted Spacing Between Div Elements After Sorting with Jqui_Sortable
What Is Better: CSS Media Queries or Jquery Mobile
CSS Non-Standard "Zoom" Property
Multiple Background Images Using SASS/Compass
Simulating Color Stops in Gradients for Ie
Unset Width to Revert Back to Inline HTML Attribute "Width=Xx"
Does Chrome Have Issue with Setting A:Visited CSS Properties
Hide Div on Mobile Devices, Using CSS
Typo3 Show Content from Subpages Inlcuding CSS Classes
Do Inline Elements Establish a Line Box for Their Content
Purgecss Whitelist Patterns with Tailwindcss
How Does CSS Scale Transform Affect Document Flow
Change Background of Child If Parent :Hover
Box-Sizing: How to Get Rid of the Scrollbar Padding in Firefox
There Is a 4Px Gap Below Canvas/Video/Audio Elements in HTML5