Using a general purpose CSS Selector as a mixin.

[gaurav21r]

Mixins

Just like in mixins

.border-radius(@radius){
   border-radius : @radius;
   moz-border-radius : @radius;
   webkit-border-radius : @radius;
}

a {
   .border-radius (2px);
}

Compiles to

a {
   border-radius : 2px;
   moz-border-radius : 2px;
   webkit-border-radius : 2px;
}

Lets have

input[type="text"]{
   border: 1px solid blue;
}
.inputbox {
   input[type="text"];
}

compile to

.inputbox{
   border: 1px solid blue;
}

Use Case

The main Use Case where our organisation's engineers are facing problems is when the underlying HTML is not under our control. When does that happen? JavaScript Frameworks! Take jQuery UI, Dojo, extJs, Google Closure, YUI and the like.

We really like BootStrap and would like to see it as the de facto UI framework for the web. I am sure everyone will agree, BootStrap is by far the biggest project using Less. Although amazing websites have been created with BootStrap, we don't see major JS Web Apps use BootStrap, because the HTML for their various widgets is not under our control and LESS doesn't provide any other solution.

SaSS / Stylus
SaSS3 has @extend that does exactly what I'm talking about.

Stylus also has @extend that does the same.

Similarity to CSS
The syntax as mentioned above in my example is intuitive. The makers of LESS want it to resemble CSS as much as is possible. I second that and I think this is the best way to do it. Even better than an @extend

References
There is already a fix for this as give here We plan to test it out deeper and submit a Pull Request

The issue is already referenced here, while it is the same issue, I felt the domain of the problem and the magnanimity of its importance should be further highlighted.

Hats of to LESS btw, the best thing to happen to CSS since CSS3 :)

[matthew-dean]

Just to clarify, this:

input[type="text"]{
   border: 1px solid blue;
}
.inputbox {
   input[type="text"];
}

would compile to this?

input[type="text"]{
   border: 1px solid blue;
}
.inputbox {
   border: 1px solid blue;
}

[matthew-dean]

If the above is the behavior, that seems perfectly fine as that matches the behavior of classes, currently.

[adrianheine]

Yes, that's the case.

[gaurav21r]

Yes definitely. As mentioned above, such use cases are very important, as the LESS in Bootstrap and most JS Frameworks directly apply such tag selectors and we have no control over the html.

[gaurav21r]

@MatthewDL If you think the code is fine and since @agatronic already has no objections, can you merge the pull? We'd love to have this feature in the main branch with support.

There is (I think) sufficient activity generated for the issue across the Issues in GitHub as well as here.

Besides, this is the only major thing SaSS and Stylus have (via @extend) but LESS doesn't.

[dmcass]

I just want to quickly chime in here and note that LESS is planning on implementing similar functionality to @extend in 1.4. Would that make this PR obsolete for you @gaurav21r?

see #1014

[adrianheine]

What's the reason for introducing a new syntax?

[gaurav21r]

I don't know if the current implementation of @extend is as "nonrestrictive" as this PR.

[jonschlinkert]

What is the advantage of this request? I'm not trying to be harsh, but I can't see any reason (advantage) for using this over mixins. To be clear, I completely understand the difference between this and mixins, but this request adds a layer of abstraction that encourages poor organizational habits and could only lead to messy and complicated LESS. Just because we "can" add a feature, doesn't mean we should. My vote is "no" on this one. I think it's a solution looking for a problem.

[gaurav21r]

@jonschlinkert I completely agree with you, it may lead to unorganised code. As I had mentioned above, the ONLY use case we see for this feature is the editing of LESS when the underlying HTML is not under our control.

So technically the messiness has already happened when we use any JS Framework like Dojo / extjs / jQuery UI. If you've used these frameworks before, you'll agree with me that to change structure of their widgets you'll need to hack the core js files (that builds the HTML and the class names). Neither is that feasible nor maintainable.

One of our motivations was to use it for a project where we are trying to use Bootstrap to make a Dojo theme. Someone's already done that. Bootstrap uses LESS, Dojo uses LESS but they had to use Stylus to connect them. Only because LESS has ONE feature missing thats there in Stylus, SASS and thats this!

Undoubtedly Bootstrap is the number one project that uses LESS and they have some styles applied directly to tags.

Directly adding styles to tag selectors (no class or id) is a big nono and leads to messy, un manageble code. CSS the language doesn't enforce that at a syntax level. We just want the same thing for LESS, the Language...

[garrettlancaster]

Big +1 for this, for exactly the reasons @gaurav21r describes.

[lukeapage]

I was pro this, but then extends came along. I just tried the beta and actually the above example doesn't work - but that is a bug rather than an intentional feature.

I think we have to ask ourselves - what are mixins good for and what are extends good for and which should be used for which. why does it make more sense to use mixins than extends?

[seven-phases-max]

Btw., recently (when crafting a Less highlighter) I realized that it's simply impossible to allow an arbitrary selector to be used as a mixin. The show-stopper is a selector where tag is followed by :pseudo-class:

foo:bar;

For this statement there's no way to say if it's a mixin call or a property: value; statement
(Unless the compiler has at least all possible pseudo-classes hardcoded in - which is a dead-end on its own).

---

This is just another argument for closing this request, beside the one counting that the OP originally refers to an extend functionality (not really a mixin stuff) which is implemented in Less by now.

[lukeapage]

I think I would only support this with a new syntax and I agree it doesn't seem so important now we have extend.

[gaurav21r]

I'm a little confused with extends. Can someone @lukeapage @jonschlinkert @garrettlancaster or anyone else please give an example of how extends can solve the problem with frameworks like mentioned in #1048 (comment)

[seven-phases-max]

@gaurav21r Assuming your initial example it's:

input[type="text"] {
    border: 1px solid blue;
}

.inputbox {
    &:extend(input[type="text"]);
}

See the docs.

[gaurav21r]

@seven-phases-max Thanks! This works? Well then extends pretty much does the job! I think we should close this thread now. Any objections from anyone?