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.
LESS nesting styles to mimic html layout?
Selector bloating like you illustrate as one of the "serious drawbacks" is why I would use nesting of selectors sparingly. For me, having the CSS exactly match the layout of the markup is not that significant. I can use a few sparse comments to help me know what "section" I'm in in the CSS. So let me walk through some thoughts about how I might change things.
Keep Near, not Necessarily Nested
Example
/* branding */
#branding {
h1 { }
.ticker { }
nav {
ul { }
li { }
a { }
}
}
#tagline { }
#search-form {
input { }
button { }
}
Discussion
First, note how put a comment as my section heading, rather than just using the #branding to group everything. This is my keeping of some "structure" like the html, I group by major "wrapper" headings and keep them near each other.
Second, any id tag's should be there own top level nesting group, assuming that you are correctly structuring your html to keep id's unique to a page. The only exception in my mind would be if you are using some class on the body element to switch looks on pages, and part of that look change includes a change to styling on an element selected by id (but even that may be handled by still putting id as top level; see "Utilize the Power of &" below). So I have pulled out your #tagline and #search-form from the nest under #branding.
Third, think about your design and code for minimal bloat. For example, if you have other nav elements on page (sub navs in side bars, etc.), then nesting the nav in #branding is worthwhile. Likewise, if you have other h1 or .ticker uses outside that wrapper. However, a common nest that I despise is the ul li a nest. If the only list inside nav is the ul, then there is no reason to nest the li inside it and end up with ul li in your selector string, because it is a given that all the li are located there. Likewise, if the only a tags in the nav are inside the list, then no need to nest that. Having this css...
#branding nav ul { }
#branding nav li { }
#branding nav a { }
...is just as clean and far less bloated in its selector string than the full nest version.
Utilize the power of &
I like the idea of using the & to add key parents to code. Recall the exception above about adding a class on the body element to control theming (or looks) across pages. You could nest it in the theme class, or you could do this:
Example
#branding {
.theme1 & { }
.theme2 & { }
h1 { }
.ticker { }
nav {
ul { }
li { }
a { }
}
}
Discussion
Which would then produce a selector like .theme1 #branding to change the look of the #branding by the theme class. If you needed this to change properties for the items nested in it, there are various ways you can do it (it depends so much on what structure you want your final output to look like). One way is add it only to what is needed:
Example
#branding {
.theme1 & { }
.theme2 & { }
h1 {
.theme2 & { //special code only for theme2 here }
}
.ticker { }
nav {
ul {
//main code here
.theme1 & { //special code here }
.theme2 & { }
}
li { }
a { }
}
}
Discussion
The disadvantage is some extra repetition of .theme classes in the code, while the advantage to this is that it keeps the end point targets grouped, so for example the ul above would produce code like this...
#branding nav ul {}
.theme1 #branding nav ul {}
.theme2 #branding nav ul {}
#branding nav li {}
#branding nav a {}
...which keeps the all the various ul code next to each other. Now, if the li and a elements also needed changing on theme, you would have to decide if you want to move the themeing up a level so that the ul, li and a for a particular theme are grouped next to each other by theme, or if you keep it at the lowest level like above so that each ul, li, and a stay grouped by endpoint tag that is actually being styled.
Of course, using & to append normally is still useful in nesting, so...
a {
&:hover {}
}
...to produce the a:hover {} info no matter how deeply nested the a may be is a great use of nesting and & combined.
Conclusion
There is certainly more that could be said on the subject. The key is to utilize the power of preprocessors where it is needed, not just because it is available. For me, mixins are the more useful part of preprocessors as opposed to nesting.
Overriding nesting, to stay in scope
I've done some extensive commentary on this both in this answer and this answer. In your particular case, it would be this:
LESS
.module {
h1 {
float: left;
body.secondary & {
float: right;
}
}
}
CSS Output
.module h1 {
float: left;
}
body.secondary .module h1 {
float: right;
}
The key is to realize that the & is not just for targeting the "parent" per se in the html structure, but rather is a string replacement for the entire nested structure it sits within. So in my solution above, the nested LESS "parent" is .module h1 which is the string replaced at the & point in the body.secondary & construct nested within it.
Less CSS - reverse parent of parent
I pasted your code here: http://less2css.org/
Instead of:
#parent1 {
#parent2 {
#grandparent & & {
/* stuff */
}
}
}
I tried
#parent1 {
#parent2 {
#grandparent & {
/* stuff */
}
}
}
And that equates to:#grandparent #parent1 #parent2 { /* stuff */ }
Is this what you're asking for?
LESS CSS - accessing classes further up the dom tree from within a nested class
Yes! (an update)
When I tested this here, it worked!
.container {
.logo {
background:url(/images/logo.gif);
.svg & {
background:url(/images/svg-logo.svg);
}
}
}
How to specify a html tag on a LESS CSS nested class?
I kinda don't see much of a point in trying to nest these two rules if they won't share any common styles within the exit class.
That said, if you still want to nest them, remember that in selectors, element names always precede other simple selectors. Try placing the & after the element name and see if it works:
.exit{
article&{
width:260px; height:200px; top:315px; left:505px;
figure{background-color:@exit-bg;}
.box:hover{.perspective-box(se, 10, @exit-shadow);}
}
section&{
.box:hover{.perspective-box(nw, 10, @exit-shadow);}
.intro figcaption:hover{background:@exit-hover;}
}
}
LESS condition based on CSS class to set a LESS variable
The LESS file cannot read the actual class applied to the html body element at run time (you would probably need to implement a javascript solution to do something like that).
If you just want to have all themed css ready for use based on the body class, the best way to implement this to have all the necessary theme based css in a mixin, then apply it under the theme classes. This reduces code duplication. For example:
LESS
//mixin with all css that depends on your color
.mainThemeDependentCss() {
@contrast: lighten(@themeColor, 20%);
h1 {color: @themeColor;}
p {background-color: @contrast;}
}
//use the mixin in the themes
body.themeBlue {
@themeColor: blue;
.mainThemeDependentCss();
}
body.themeRed {
@themeColor: red;
.mainThemeDependentCss();
}
CSS Output
body.themeBlue h1 {
color: #0000ff;
}
body.themeBlue p {
background-color: #6666ff;
}
body.themeRed h1 {
color: #ff0000;
}
body.themeRed p {
background-color: #ff6666;
}
For some other answers that deal with aspects or ways of theming, see:
- LESS CSS - Change variable value for theme colors depending on body class
- LESS.css variable depending on class
- LESS CSS: abusing the & Operator when nesting?
Adding parent css class to mixins using LESS constructs such as td&
#1
Possible solution is to provide class name to append as mixin parameter:
.responsive-invisibility(@postfix) {
@{postfix},
tr@{postfix},
th@{postfix},
td@{postfix} {display: none !important;}
}
body.force-sm-viewport-or-higher {
.responsive-invisibility(~'.visible-xs');
/* more stuff */
}
Edit: you need to define that mixin on you own, i.e. do not modify the original Bootstrap .responsive-invisibility, then you'll be able to use both w/o conflict.
#2
A future-proof compatible solution similar to the solution suggested in @Scotts answer (and isnpuired by it) but producing less junk:
.invisible_ {
.responsive-invisibility(); // use original Bootstrap mixin
}
.responsive-invisibility(@postfix) {
@{postfix},
tr@{postfix},
th@{postfix},
td@{postfix} {&:extend(.invisible_);}
}
body.force-sm-viewport-or-higher {
.responsive-invisibility(~'.visible-xs');
/* more stuff */
}
This way you won't have to modify invisibility styles if they do that in Bootstrap (but you still have to keep tracking the tr, th, td list in case they change it).
Less Immediate Parent Selector
A Base Example
It partly depends upon how you structure your LESS code. There is currently no way to do this with a normal nested structure. However, take the following example, where the .grandchild is our final target in all cases (it must be the outermost level--I called this "end target grouping" in a previous answer before LESS added documentation about using & as a parent selector):
LESS
.grandchild {
grandchild: 1;
.child & {
child: 1;
.parent & {
parent: 1;
.grandparent & {
grandparent: 1;
}
}
}
}
CSS Output
.grandchild {
grandchild: 1;
}
.child .grandchild {
child: 1;
}
.parent .child .grandchild {
parent: 1;
}
.grandparent .parent .child .grandchild {
grandparent: 1;
}
As you can see, any code nested in the first level only has the end target of .grandchild in its selector string. Each level one goes "down" in the nest, one is actually going "up" in selector specificity. So to target just the "immediate parent" for the selector string, place it in the .child of this example.
Hovers Still Work
LESS
.grandchild {
grandchild: 1;
&:hover {
grandchildhover: 1;
}
.child & {
child: 1;
.parent & {
parent: 1;
.grandparent & {
grandparent: 1;
&:hover {
grandchildhover: 1;
}
}
}
}
}
This will add to the above css these two outputs:
.grandchild:hover {
grandchildhover: 1;
}
.grandparent .parent .child .grandchild:hover {
grandchildhover: 1;
}
Skip Generations
You can code it to skip some generations, like so:
LESS
.grandchild {
grandchildonly: 1;
.child & {
withchild: 1;
.parent & {
withparentchild: 1;
}
}
.parent & {
skipgenchild: 1;
}
}
CSS Output
.grandchild {
grandchildonly: 1;
}
.child .grandchild {
withchild: 1;
}
.parent .child .grandchild {
withparentchild: 1;
}
.parent .grandchild {
skipgenchild: 1;
}
Abstracted
There are various ways this could be abstracted out, such that the code does not give the appearance of a nested look (which could confuse a user). Something like this is one way (output similar to that given in first and second examples above):
.addParent(@parent) {
@parentescaped: e(@parent);
@{parentescaped} & {.setWithParentProps(@parent);}
}
.grandchild {
grandchild: 1;
&:hover {
grandchildhover: 1;
}
.addParent('.child');
.setWithParentProps('.child'){
child: 1;
.addParent('.parent');
}
.setWithParentProps('.parent'){
parent: 1;
.addParent('.grandparent');
}
.setWithParentProps('.grandparent'){
grandparent: 1;
&:hover {
morespecifichover: 1;
}
}
}
Final Comments
As seven-phases-max linked to in his comment, there is talk of adding generational precision within a normal nested context. The solution given here requires one to think "opposite" of nesting, but rather think only about the element being targeted. So the way to add a .grandchild into another selector would not be this mixin:
LESS (expecting to add a parent by normal nesting)
.another-generational-parent {
.grandchild;
}
CSS Output
.another-generational-parent {
grandchildonly: 1;
}
.child .another-generational-parent {
withchild: 1;
}
.parent .child .another-generational-parent {
withparentchild: 1;
}
It would be best to add it into the original code according to the proper place, but if that is not possible, then some repetition is needed (unless you set up some way in the original code to "insert" parents through creative mixin calling--I have no time to devout to that here).
.parent .child .grandchild {
.another-generational-parent & {
another-generational-parent: 1;
}
}
Whether such opposite coding can be useful or not all depends upon one's goals and desires in organizing the LESS code.
Related Topics
Hover on Child Without Hover Effect on Parent
Specifying Style and Weight for Google Fonts
Differencebetween Outline and Border CSS Properties
How to Apply Styles to Multiple Classes at Once
Why Put in Front of the File Name "_" or "_" in SCSS/Css
How to Select the Last N Items with Nth-Child
Using Twitter Bootstrap 2.0 - How to Make Equal Column Heights
Display:Inline Resets Height and Width
How to Make CSS A:Active Work After the Click
Zebra Striping a Table with Hidden Rows Using CSS3
How to Render Multiple Columns with Markdown in Github Readme
Sass @Each Variable Interpolation
Build List of Selectors with Less
Bootstrap 4 Navbar and Content Fill Height Flexbox