{var%20f='http://v.t.sina.com.cn/share/share.php?appkey=1515056452',u=z||d.location,p=['&url=',e(u),'&title=',e(t||d.title),'&source=',e(r),'&sourceUrl=',e(l),'&content=',c||'gb2312','&pic=',e(p||'')].join('');function%20a(){if(!window.open([f,p].join(''),'mb',['toolbar=0,status=0,resizable=1,width=440,height=430,left=',(s.width-440)/2,',top=',(s.height-430)/2].join('')))u.href=[f,p].join('');};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else%20a();})(screen,document,encodeURIComponent,'','','https://www.manongdao.com/data/attach/logo/logo.png', '推荐 \"骚年 ilove 的问题《LESS CSS: abusing the & Operator when nesting?》','https://www.manongdao.com/q-69176.html','页面编码gb2312|utf-8默认gb2312'));){kind=link}
Less uses the & Operator to enhance the possibilities for nesting.
.header { color: black;
.navigation { font-size: 12px;
&.class { text-decoration: none }
}
}
which causes a substitution of the & with the parent selector and results in a concatentation of the actual selector right to the parent selector: .header .navigation.class instead of the normal appending, which would result in .class being a decendant: .header .navigation .class.
Now what also is possible is the following (see also here):
.header { color: black;
.navigation { font-size: 12px;
#some-id & .foo { text-decoration: none }
}
}
which would result in the following: #some-id .header .navigation .foo try here . The substition takes place and i have prepended a selector (#some-id) to my parent selector.
Besides the fact that I would never code this way, since this probably messes up your stylesheet in no time, my question:
As this functionality is not documented, is it a feature or more likely a bug?
Which are possible side-effects?
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
bodyelement 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.Now the questions to ask are, just looking at the links, of the two following methods, which...
"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)
CSS Output (approx. 87 lines of output, organized by theme of course)
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)
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)
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
.textLinkelements hadtext-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.textLinkselector (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.It's not abuse of the
&combinator at all; you can place it anywhere in a nested selector and it'll be substituted with whatever is above it (its so-called parent selector):Notice that it says "concatenated"; it doesn't say you can only either prepend or append the parent selector to the nested selector. Concatenation doesn't work in any specific direction only.
Further, the word "descendant" has to do with the nature of nested selectors being treated as though they were linked by the descendant combinator by default. In no way does that inherently limit the use of
&to descendants only, nor does it imply that the parent selector has to represent a parent or ancestor element in such a way that the nested selector may only be appended to it, and not prepended or even inserted into the middle of it.