Add Sass like extend #509

Closed
wants to merge 3 commits into
from

Conversation

Projects
None yet
@hokaccha
Contributor

hokaccha commented Dec 5, 2011

Sass extend is here.
http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#extend

More simple syntax, use +.

.foo {
  width: 100px;
}
.bar {
  +.foo;
}

converted this.

.foo, bar {
  width: 100px;
}

See also test code.

@cloudhead

This comment has been minimized.

Show comment
Hide comment
@cloudhead

cloudhead Dec 7, 2011

Member

Nice work, I'll have a look!

Member

cloudhead commented Dec 7, 2011

Nice work, I'll have a look!

@madevelopers

This comment has been minimized.

Show comment
Hide comment
@madevelopers

madevelopers Dec 12, 2011

and the output is also grouped. nice.

and the output is also grouped. nice.

@cloudhead

This comment has been minimized.

Show comment
Hide comment
@cloudhead

cloudhead Dec 13, 2011

The ; here should be a ,.

The ; here should be a ,.

This comment has been minimized.

Show comment
Hide comment
Owner

hokaccha replied Dec 13, 2011

@aziz

This comment has been minimized.

Show comment
Hide comment
@aziz

aziz Mar 31, 2012

I really like to see this one get merged into LESS. It's obviously missing this feature and will help us generate lighter and leaner css files by reusing instead of repeating.

a big 👍

aziz commented Mar 31, 2012

I really like to see this one get merged into LESS. It's obviously missing this feature and will help us generate lighter and leaner css files by reusing instead of repeating.

a big 👍

@jmgunn87

This comment has been minimized.

Show comment
Hide comment
@jmgunn87

jmgunn87 Apr 29, 2012

Yeah, I like this as well. Is this going to be merged or what?

Yeah, I like this as well. Is this going to be merged or what?

@davidhund

This comment has been minimized.

Show comment
Hide comment
@davidhund

davidhund May 16, 2012

I also would love to know if/when this is going to be implemented.

I also would love to know if/when this is going to be implemented.

@rowanmanning

This comment has been minimized.

Show comment
Hide comment
@rowanmanning

rowanmanning May 30, 2012

It'd be awesome to get something like this into LESS. Any plans to merge?

It'd be awesome to get something like this into LESS. Any plans to merge?

@icholy

This comment has been minimized.

Show comment
Hide comment

icholy commented Jun 15, 2012

+1

@kadamwhite

This comment has been minimized.

Show comment
Hide comment
@kadamwhite

kadamwhite Jun 15, 2012

Another +1 to this, it'd be a huge help!

Another +1 to this, it'd be a huge help!

@albohlabs

This comment has been minimized.

Show comment
Hide comment
@albohlabs

albohlabs Jun 15, 2012

Nice one. +1

Nice one. +1

@sturobson

This comment has been minimized.

Show comment
Hide comment
@sturobson

sturobson Jun 26, 2012

+1 can we get this merged into LESS please. It'll help loads, really.

+1 can we get this merged into LESS please. It'll help loads, really.

@chrisui

This comment has been minimized.

Show comment
Hide comment
@chrisui

chrisui Jun 26, 2012

+1 I feel this is the one major piece of functionality LESS is missing.

(Also: more +1's from another issue: #759)

chrisui commented Jun 26, 2012

+1 I feel this is the one major piece of functionality LESS is missing.

(Also: more +1's from another issue: #759)

@icholy icholy referenced this pull request Jun 26, 2012

Closed

Selector Inheritance #759

@json-uk

This comment has been minimized.

Show comment
Hide comment
@json-uk

json-uk Jul 9, 2012

Has there been any movement on this? Why hasn't the developer pulled this in? All the comparisons between SASS and LESS point to this as one of the killer features. Cloudhead your community desparatwly wants this feature!!!!

json-uk commented Jul 9, 2012

Has there been any movement on this? Why hasn't the developer pulled this in? All the comparisons between SASS and LESS point to this as one of the killer features. Cloudhead your community desparatwly wants this feature!!!!

@chrisui

This comment has been minimized.

Show comment
Hide comment
@chrisui

chrisui Jul 9, 2012

Any chance of taking a look @cloudhead ?

chrisui commented Jul 9, 2012

Any chance of taking a look @cloudhead ?

@json-uk

This comment has been minimized.

Show comment
Hide comment
@json-uk

json-uk Jul 20, 2012

Can someone with prove ledges please add this and release it? This pull request is months old. The LESS community will be very grateful!

json-uk commented Jul 20, 2012

Can someone with prove ledges please add this and release it? This pull request is months old. The LESS community will be very grateful!

@lukeapage

This comment has been minimized.

Show comment
Hide comment
@lukeapage

lukeapage Jul 20, 2012

Member

we will get round to considering this, but I think bugs are higher priority.

Member

lukeapage commented Jul 20, 2012

we will get round to considering this, but I think bugs are higher priority.

@kadamwhite

This comment has been minimized.

Show comment
Hide comment
@kadamwhite

kadamwhite Jul 21, 2012

I can't disagree with the importance of bug fixes, @agatronic, but I'd also second @dtigraphics that time and time again I hear people recommend Sass over LESS because LESS lacks this feature... It's a useful bit of functionality that would really improve the experience of using the tool, IMO, and we'd love to see this prioritized as soon as new features are under discussion.

In the meantime, what can we as a community do to test/support this request? There's a lot of us on this thread by now, if there is anything we can do to speed up the inclusion of this feature we would love to help!

I can't disagree with the importance of bug fixes, @agatronic, but I'd also second @dtigraphics that time and time again I hear people recommend Sass over LESS because LESS lacks this feature... It's a useful bit of functionality that would really improve the experience of using the tool, IMO, and we'd love to see this prioritized as soon as new features are under discussion.

In the meantime, what can we as a community do to test/support this request? There's a lot of us on this thread by now, if there is anything we can do to speed up the inclusion of this feature we would love to help!

@leopic

This comment has been minimized.

Show comment
Hide comment
@leopic

leopic Jul 21, 2012

If you want this REALLY bad you could just fork the repo and make your own build in the mean time ;)

leopic commented Jul 21, 2012

If you want this REALLY bad you could just fork the repo and make your own build in the mean time ;)

@icholy

This comment has been minimized.

Show comment
Hide comment
@icholy

icholy Jul 21, 2012

@leopic and then have to go back and fix all your code when a slightly modified version of this feature gets merged.

icholy commented Jul 21, 2012

@leopic and then have to go back and fix all your code when a slightly modified version of this feature gets merged.

@leopic

This comment has been minimized.

Show comment
Hide comment
@leopic

leopic Jul 21, 2012

Well you can't have your cake and eat it too, IMHO the whole idea of exposing your source code is that people don't have to wait 8 months before trying out a new feature gets merged, as long as you can make a build you can run your own flavor of your favorite tool =)

leopic commented Jul 21, 2012

Well you can't have your cake and eat it too, IMHO the whole idea of exposing your source code is that people don't have to wait 8 months before trying out a new feature gets merged, as long as you can make a build you can run your own flavor of your favorite tool =)

@icholy

This comment has been minimized.

Show comment
Hide comment
@icholy

icholy Jul 21, 2012

@leopic that's true when you're hacking at personal projects. But maintaining a patch like this in production quickly turns into a huge pita.

icholy commented Jul 21, 2012

@leopic that's true when you're hacking at personal projects. But maintaining a patch like this in production quickly turns into a huge pita.

@json-uk

This comment has been minimized.

Show comment
Hide comment
@json-uk

json-uk Jul 21, 2012

I think it's clear that there's a very large community of developers who use, and would like to help the project to keep it alive. Let's be honest - the ratio of open bugs to closed is staggering. It's starting to appear as though the project has lost momentum. What can this community do in order to keep this easy to use and powerful tool alive?

You brought up a good point about the difference between personal and public projects. It's important to maintain momentum to ensure LESS doesn't fade away like so many other great tools!

Jason Chandler
jc@designtoinspire.net
http://dtigraphics.net
Design, the way nature intended.

On Jul 20, 2012, at 10:46 PM, ilia choly reply@reply.github.com wrote:

@leopic that's true when you're hacking at personal projects. But maintaining a patch like this in production quickly turns into a huge pita.


Reply to this email directly or view it on GitHub:
#509 (comment)

json-uk commented Jul 21, 2012

I think it's clear that there's a very large community of developers who use, and would like to help the project to keep it alive. Let's be honest - the ratio of open bugs to closed is staggering. It's starting to appear as though the project has lost momentum. What can this community do in order to keep this easy to use and powerful tool alive?

You brought up a good point about the difference between personal and public projects. It's important to maintain momentum to ensure LESS doesn't fade away like so many other great tools!

Jason Chandler
jc@designtoinspire.net
http://dtigraphics.net
Design, the way nature intended.

On Jul 20, 2012, at 10:46 PM, ilia choly reply@reply.github.com wrote:

@leopic that's true when you're hacking at personal projects. But maintaining a patch like this in production quickly turns into a huge pita.


Reply to this email directly or view it on GitHub:
#509 (comment)

@jmgunn87

This comment has been minimized.

Show comment
Hide comment
@jmgunn87

jmgunn87 Jul 21, 2012

Well let's fork and get on with it. Who's first?

Well let's fork and get on with it. Who's first?

@lukeapage

This comment has been minimized.

Show comment
Hide comment
@lukeapage

lukeapage Jul 22, 2012

Member

before you do that please read bug #867 and move this conversation there. we are doing our best!

Member

lukeapage commented Jul 22, 2012

before you do that please read bug #867 and move this conversation there. we are doing our best!

@superfunkminister

This comment has been minimized.

Show comment
Hide comment
@superfunkminister

superfunkminister Aug 21, 2012

so can this happen now? would be SO AWESOME

so can this happen now? would be SO AWESOME

@kadamwhite

This comment has been minimized.

Show comment
Hide comment
@kadamwhite

kadamwhite Aug 30, 2012

@agatronic - Thanks for all the work you and the others are doing to maintain this project. Please let us know if we can do anything to vet out this PR... While it is a new feature/increased scope, I have semi-regularly heard people express the lack of extend as the sole reason they are choosing SCSS over LESS and I'd love to be involved in the conversation about how we might address that issue.

@agatronic - Thanks for all the work you and the others are doing to maintain this project. Please let us know if we can do anything to vet out this PR... While it is a new feature/increased scope, I have semi-regularly heard people express the lack of extend as the sole reason they are choosing SCSS over LESS and I'd love to be involved in the conversation about how we might address that issue.

@lukeapage

This comment has been minimized.

Show comment
Hide comment
@lukeapage

lukeapage Aug 30, 2012

Member

this one is just waiting for someone to pick it up, evaluate etc. we have had alot of interest and @cloudhead seemed to be interested in it, so I could have a go at merging soon.

Member

lukeapage commented Aug 30, 2012

this one is just waiting for someone to pick it up, evaluate etc. we have had alot of interest and @cloudhead seemed to be interested in it, so I could have a go at merging soon.

@DesignByOnyx

This comment has been minimized.

Show comment
Hide comment
@DesignByOnyx

DesignByOnyx Oct 4, 2012

Just wanted to make a request for a different syntax. The "+" sign is a next sibling selector that is easy to confuse with the syntax proposed here. Here is an example of real world code, which could be really confusing when breezing over code.

.shared {
    color: red;
    font-size: 12px;
}

h3 {
    +.shared;
    font-size: 20px;

    + .shared {
        font-size: 18px;
    }
}

I do like the "+" syntax for extending... would it be wise to do something like a double plus "++":

h3 {
    font-size: 20px;
    ++.shared;
}

Just wanted to make a request for a different syntax. The "+" sign is a next sibling selector that is easy to confuse with the syntax proposed here. Here is an example of real world code, which could be really confusing when breezing over code.

.shared {
    color: red;
    font-size: 12px;
}

h3 {
    +.shared;
    font-size: 20px;

    + .shared {
        font-size: 18px;
    }
}

I do like the "+" syntax for extending... would it be wise to do something like a double plus "++":

h3 {
    font-size: 20px;
    ++.shared;
}
@jonschlinkert

This comment has been minimized.

Show comment
Hide comment
@jonschlinkert

jonschlinkert Oct 11, 2012

Contributor

I completely agree that the + symbol alone is not a good idea for the reasons stated by @DesignByOnyx. I think the ++ is a good idea, it's still clean, and it's very obvious compared to a single +.

Contributor

jonschlinkert commented Oct 11, 2012

I completely agree that the + symbol alone is not a good idea for the reasons stated by @DesignByOnyx. I think the ++ is a good idea, it's still clean, and it's very obvious compared to a single +.

@Soviut

This comment has been minimized.

Show comment
Hide comment
@Soviut

Soviut Oct 11, 2012

Will this syntax work inline in a selector?

h3 ++ .shared {
   font-size: 20px;
}

The space after the ++ could potentially be optional, but I think it might actually fit better into the CSS syntax as an homage to ancestor syntax.

Soviut commented Oct 11, 2012

Will this syntax work inline in a selector?

h3 ++ .shared {
   font-size: 20px;
}

The space after the ++ could potentially be optional, but I think it might actually fit better into the CSS syntax as an homage to ancestor syntax.

@SomMeri SomMeri referenced this pull request in SomMeri/less4j Oct 11, 2012

Closed

Extending Mixins #31

@DesignByOnyx

This comment has been minimized.

Show comment
Hide comment
@DesignByOnyx

DesignByOnyx Oct 11, 2012

@Soviut - I am not sure what your syntax is supposed to imply. The double plus syntax is not really a selector but a LESS version of SASS' @extend operation. The example you give implies that ++ is a selector of some sorts. Let me show LESS code, followed by the compiled CSS:

// LESS
.shared {
    font-size: 12px;
    color: red;
}

h3 {
    ++ .shared;

    font-size: 16px;

    + .shared {
        color: blue;
    }
}

Would produce the following CSS:

.shared,
h3 {
    font-size: 12px;
    color: red;
}

h3 {
    font-size: 16px;
}

h3 + .shared {
    color: blue;
}

I also want to take this opportunity to say that something like ++ would be easier for the parsing engine to catch. I am up for any syntax which is not just a simple + sign or any other standard CSS selector.

@Soviut - I am not sure what your syntax is supposed to imply. The double plus syntax is not really a selector but a LESS version of SASS' @extend operation. The example you give implies that ++ is a selector of some sorts. Let me show LESS code, followed by the compiled CSS:

// LESS
.shared {
    font-size: 12px;
    color: red;
}

h3 {
    ++ .shared;

    font-size: 16px;

    + .shared {
        color: blue;
    }
}

Would produce the following CSS:

.shared,
h3 {
    font-size: 12px;
    color: red;
}

h3 {
    font-size: 16px;
}

h3 + .shared {
    color: blue;
}

I also want to take this opportunity to say that something like ++ would be easier for the parsing engine to catch. I am up for any syntax which is not just a simple + sign or any other standard CSS selector.

@Soviut

This comment has been minimized.

Show comment
Hide comment
@Soviut

Soviut Oct 11, 2012

Thanks for the explanation. I understood what it was supposed to be used for before, but I was wondering if it could work in the selector syntax.

Regardless, I'm in favour of ++

Soviut commented Oct 11, 2012

Thanks for the explanation. I understood what it was supposed to be used for before, but I was wondering if it could work in the selector syntax.

Regardless, I'm in favour of ++

@lukeapage

This comment has been minimized.

Show comment
Hide comment
@lukeapage

lukeapage Oct 18, 2012

Member

what about using the & parent selector in the context of calling a mixin .. e.g.

.shared {
    font-size: 12px;
    color: red;
}

h3 {
    &,.shared;
    font-size: 16px;
}

h2 {
    &.shared;
    font-size: 10px;
}

becomes

h3, .shared {
    font-size: 12px;
    color: red;
}
h3 {
    font-size: 16px;
}
h2.shared {
    font-size: 12px;
    color: red;
}
h2 {
    font-size: 10px;
}

hrmm.. maybe ++ is better just trying to think what is obvious looking and natural.

Member

lukeapage commented Oct 18, 2012

what about using the & parent selector in the context of calling a mixin .. e.g.

.shared {
    font-size: 12px;
    color: red;
}

h3 {
    &,.shared;
    font-size: 16px;
}

h2 {
    &.shared;
    font-size: 10px;
}

becomes

h3, .shared {
    font-size: 12px;
    color: red;
}
h3 {
    font-size: 16px;
}
h2.shared {
    font-size: 12px;
    color: red;
}
h2 {
    font-size: 10px;
}

hrmm.. maybe ++ is better just trying to think what is obvious looking and natural.

@dmcass

This comment has been minimized.

Show comment
Hide comment
@dmcass

dmcass Oct 18, 2012

Contributor

Honestly I kind of prefer the explicit @extend instead. Maybe that's just me, but +, ++, and & all seem like they could exist as mistakes within a LESS file...something that could end up being difficult to hunt down. If we do end up using some kind of symbol for it, I'd prefer to use something unique that neither CSS or LESS currently has implemented, and I'd still recommend aliasing @extend.

Contributor

dmcass commented Oct 18, 2012

Honestly I kind of prefer the explicit @extend instead. Maybe that's just me, but +, ++, and & all seem like they could exist as mistakes within a LESS file...something that could end up being difficult to hunt down. If we do end up using some kind of symbol for it, I'd prefer to use something unique that neither CSS or LESS currently has implemented, and I'd still recommend aliasing @extend.

@DesignByOnyx

This comment has been minimized.

Show comment
Hide comment
@DesignByOnyx

DesignByOnyx Oct 18, 2012

I think I agree with @dmcass the most here. LESS already comes with functions to darken(), lighten(), fade(), etc. It seems most proper to have an extend( @selector ) function. I don't agree with the leading @ sign, as that's syntax for SASS... but nonetheless - my vote is for a function.

I think I agree with @dmcass the most here. LESS already comes with functions to darken(), lighten(), fade(), etc. It seems most proper to have an extend( @selector ) function. I don't agree with the leading @ sign, as that's syntax for SASS... but nonetheless - my vote is for a function.

@matthew-dean

This comment has been minimized.

Show comment
Hide comment
@matthew-dean

matthew-dean Oct 31, 2012

Member

If this makes it into LESS, this has to really be run through the paces. There's a lot of opportunities to lead to confusion here. Questions like: does extending a class / selector extend every mention of it everywhere, in any combination of other classes? How often will this break the cascading inheritance model? And I think this syntax could be potentially confusing:

.myClass {
  ++.topClass;
  + .sibling;
}
Member

matthew-dean commented Oct 31, 2012

If this makes it into LESS, this has to really be run through the paces. There's a lot of opportunities to lead to confusion here. Questions like: does extending a class / selector extend every mention of it everywhere, in any combination of other classes? How often will this break the cascading inheritance model? And I think this syntax could be potentially confusing:

.myClass {
  ++.topClass;
  + .sibling;
}
@matthew-dean

This comment has been minimized.

Show comment
Hide comment
@matthew-dean

matthew-dean Oct 31, 2012

Member

@cloudhead This > might make more sense, as a kind of reference pointer to the root class.

.seriousError {
  > .error;
  >.attention;  // (With or without space)
}

UPDATE: Wait, ha, never mind, > is already a CSS character.

Member

matthew-dean commented Oct 31, 2012

@cloudhead This > might make more sense, as a kind of reference pointer to the root class.

.seriousError {
  > .error;
  >.attention;  // (With or without space)
}

UPDATE: Wait, ha, never mind, > is already a CSS character.

@cloudhead

This comment has been minimized.

Show comment
Hide comment
@cloudhead

cloudhead Oct 31, 2012

Member

But > means something already.

< is used in some languages, ex ruby to specify inheritance: Cat < Animal

Member

cloudhead commented Oct 31, 2012

But > means something already.

< is used in some languages, ex ruby to specify inheritance: Cat < Animal

@matthew-dean

This comment has been minimized.

Show comment
Hide comment
@matthew-dean

matthew-dean Oct 31, 2012

Member

Yes, I caught that directly after. Okay, since there's some inheritance of Ruby concepts, and not specifically a reserved character, < could work. Hmm....

Member

matthew-dean commented Oct 31, 2012

Yes, I caught that directly after. Okay, since there's some inheritance of Ruby concepts, and not specifically a reserved character, < could work. Hmm....

@lukeapage

This comment has been minimized.

Show comment
Hide comment
@lukeapage

lukeapage Oct 31, 2012

Member

@matthewdl regarding how it works, the general idea has been to "do what sass does" because thats what people find really useful over there and I think that is quite well understood. If you look at the examples in the test cases for some time you'll see the idea of how it works is already quite thought out (and answering your questions above I think). More complex cases as in #1014 do need to be looked at though.

"Questions like: does extending a class / selector extend every mention of it everywhere, in any combination of other classes?"

yes

"How often will this break the cascading inheritance model? "

Not sure what you mean? What will it break?

"And I think this syntax could be potentially confusing"

the second part of the example is not currently valid less so it would syntax error. what do you mean?

I like @cloudhead's suggestion for <.

But yes.. I am here to try to sort this issue out. I'm for it because its a hotly asked for request seems like it adds value and is already implemented. I'll let one of the active supporters of it answer your questions.

Member

lukeapage commented Oct 31, 2012

@matthewdl regarding how it works, the general idea has been to "do what sass does" because thats what people find really useful over there and I think that is quite well understood. If you look at the examples in the test cases for some time you'll see the idea of how it works is already quite thought out (and answering your questions above I think). More complex cases as in #1014 do need to be looked at though.

"Questions like: does extending a class / selector extend every mention of it everywhere, in any combination of other classes?"

yes

"How often will this break the cascading inheritance model? "

Not sure what you mean? What will it break?

"And I think this syntax could be potentially confusing"

the second part of the example is not currently valid less so it would syntax error. what do you mean?

I like @cloudhead's suggestion for <.

But yes.. I am here to try to sort this issue out. I'm for it because its a hotly asked for request seems like it adds value and is already implemented. I'll let one of the active supporters of it answer your questions.

@matthew-dean

This comment has been minimized.

Show comment
Hide comment
@matthew-dean

matthew-dean Oct 31, 2012

Member

Yep, it seems like the consensus is to put it in. I just want to raise questions so that a) we fully understand what the goals are and what devs want to accomplish, b) that we don't automatically assume that just because SASS solved something a certain way doesn't mean it's the only or best way to do so.

In the case of inheritance, I just mean that when things are grouped, the order of properties / selectors change, which can lead to unexpected output, whereas the current additive model of LESS, while more verbose in output, preserves declaration (cascading) order. No doubt SASS comes up against the same shortcomings, and probably in many cases, devs might make the case that the value outweighs the added complexity.

Which part was not valid LESS?

Member

matthew-dean commented Oct 31, 2012

Yep, it seems like the consensus is to put it in. I just want to raise questions so that a) we fully understand what the goals are and what devs want to accomplish, b) that we don't automatically assume that just because SASS solved something a certain way doesn't mean it's the only or best way to do so.

In the case of inheritance, I just mean that when things are grouped, the order of properties / selectors change, which can lead to unexpected output, whereas the current additive model of LESS, while more verbose in output, preserves declaration (cascading) order. No doubt SASS comes up against the same shortcomings, and probably in many cases, devs might make the case that the value outweighs the added complexity.

Which part was not valid LESS?

@jonschlinkert

This comment has been minimized.

Show comment
Hide comment
@jonschlinkert

jonschlinkert Oct 31, 2012

Contributor

@matthewdl well said, this conversation is exactly what I was hoping would happen once an experimental branch was put up.

I put this gist up to summarize proposals to date (please comment on the gist if I missed or mischaracterized something): https://gist.github.com/3989438

Here is my proposal:

E:extend(selector) {...}

So rather than using combinators as previously suggested, this syntax leverages a concept that already exists in CSS for targeting elements, attributes, selectors, classes, ids, etc. We already do:

.foo:nth-child(3) {...}

and the :not(selector) even allows you to target a comma separated list of elements.

.foo:not(.bar, .baz) {...}

Some examples:

.alert:extend(.alert-important, .alert-danger) {
    background: red;
}

or

.alert {
    background: red;
    &:extend(.alert-important, .alert-danger);
}

or

.alert:extend(.alert-important, .alert-danger) {
    background: red;
    .alert-header:extend(.modal-header) {...}
}
Contributor

jonschlinkert commented Oct 31, 2012

@matthewdl well said, this conversation is exactly what I was hoping would happen once an experimental branch was put up.

I put this gist up to summarize proposals to date (please comment on the gist if I missed or mischaracterized something): https://gist.github.com/3989438

Here is my proposal:

E:extend(selector) {...}

So rather than using combinators as previously suggested, this syntax leverages a concept that already exists in CSS for targeting elements, attributes, selectors, classes, ids, etc. We already do:

.foo:nth-child(3) {...}

and the :not(selector) even allows you to target a comma separated list of elements.

.foo:not(.bar, .baz) {...}

Some examples:

.alert:extend(.alert-important, .alert-danger) {
    background: red;
}

or

.alert {
    background: red;
    &:extend(.alert-important, .alert-danger);
}

or

.alert:extend(.alert-important, .alert-danger) {
    background: red;
    .alert-header:extend(.modal-header) {...}
}
@SomMeri

This comment has been minimized.

Show comment
Hide comment
@SomMeri

SomMeri Oct 31, 2012

Member

I may be wrong, bug googling "less extend" will probably find less documentation while googling "less ++" will probably find a lot of random sites. Plus, if it is named extend I can safely guess what it does without googling it or remembering special symbols table.

Member

SomMeri commented Oct 31, 2012

I may be wrong, bug googling "less extend" will probably find less documentation while googling "less ++" will probably find a lot of random sites. Plus, if it is named extend I can safely guess what it does without googling it or remembering special symbols table.

@DesignByOnyx

This comment has been minimized.

Show comment
Hide comment
@DesignByOnyx

DesignByOnyx Oct 31, 2012

I agree that a very declarative "extend" syntax would be best, however
arguments have been made earlier in this thread against this due to
paradigms already set in LESS. @jonschlinkert made a great comeback to
this argument that now is as good a time as any to start a new way of doing
things.

(I also think it will help developers who have to switch between LESS and
SASS on a daily basis).

Also, Notepad++ has a great turnout in a google search... just saying ;)

~Ryan

On Wed, Oct 31, 2012 at 5:50 PM, Mária Jurčovičová <notifications@github.com

wrote:

I may be wrong, bug googling "less extend" will probably find less
documentation while googling "less ++" will probably find a lot of random
sites. Plus, if it is named extend I can safely guess what it does without
googling it or remembering special symbols table.


Reply to this email directly or view it on GitHubhttps://github.com/cloudhead/less.js/pull/509#issuecomment-9965104.

I agree that a very declarative "extend" syntax would be best, however
arguments have been made earlier in this thread against this due to
paradigms already set in LESS. @jonschlinkert made a great comeback to
this argument that now is as good a time as any to start a new way of doing
things.

(I also think it will help developers who have to switch between LESS and
SASS on a daily basis).

Also, Notepad++ has a great turnout in a google search... just saying ;)

~Ryan

On Wed, Oct 31, 2012 at 5:50 PM, Mária Jurčovičová <notifications@github.com

wrote:

I may be wrong, bug googling "less extend" will probably find less
documentation while googling "less ++" will probably find a lot of random
sites. Plus, if it is named extend I can safely guess what it does without
googling it or remembering special symbols table.


Reply to this email directly or view it on GitHubhttps://github.com/cloudhead/less.js/pull/509#issuecomment-9965104.

@matthew-dean

This comment has been minimized.

Show comment
Hide comment
@matthew-dean

matthew-dean Oct 31, 2012

Member

@jonschlinkert Your proposed syntax is pretty close to what I was envisioning in my head. It feels more elegant, and like mixin guards for LESS which mimic media query syntax, it feels more like an extension of CSS, and therefore, more LESS-like than other symbols.

Plus, by making :extend in the declaration, it more accurately describes that this class definition will be merged with other selectors (and which ones). Having the extend declaration arbitrarily placed somewhere within the list of properties doesn't feel right for an extending behavior. This is on par with, say, the ":not" psuedo-class, and some of the jQuery pseudo-class extensions which mimic CSS.

Very nice work. This syntax, in itself, makes me like the whole concept of extend even more, because it's much more clearly defined.

+1 to @jonschlinkert's syntax

Member

matthew-dean commented Oct 31, 2012

@jonschlinkert Your proposed syntax is pretty close to what I was envisioning in my head. It feels more elegant, and like mixin guards for LESS which mimic media query syntax, it feels more like an extension of CSS, and therefore, more LESS-like than other symbols.

Plus, by making :extend in the declaration, it more accurately describes that this class definition will be merged with other selectors (and which ones). Having the extend declaration arbitrarily placed somewhere within the list of properties doesn't feel right for an extending behavior. This is on par with, say, the ":not" psuedo-class, and some of the jQuery pseudo-class extensions which mimic CSS.

Very nice work. This syntax, in itself, makes me like the whole concept of extend even more, because it's much more clearly defined.

+1 to @jonschlinkert's syntax

@Soviut

This comment has been minimized.

Show comment
Hide comment
@Soviut

Soviut Nov 1, 2012

The documentation can list "extending" and "extension" to make the
association more concrete when searching.

On Oct 31, 2012, at 6:50 PM, "Mária Jurčovičová" notifications@github.com
wrote:

I may be wrong, bug googling "less extend" will probably find less
documentation while googling "less ++" will probably find a lot of random
sites. Plus, if it is named extend I can safely guess what it does without
googling it or remembering special symbols table.


Reply to this email directly or view it on
GitHubhttps://github.com/cloudhead/less.js/pull/509#issuecomment-9965104.

Soviut commented Nov 1, 2012

The documentation can list "extending" and "extension" to make the
association more concrete when searching.

On Oct 31, 2012, at 6:50 PM, "Mária Jurčovičová" notifications@github.com
wrote:

I may be wrong, bug googling "less extend" will probably find less
documentation while googling "less ++" will probably find a lot of random
sites. Plus, if it is named extend I can safely guess what it does without
googling it or remembering special symbols table.


Reply to this email directly or view it on
GitHubhttps://github.com/cloudhead/less.js/pull/509#issuecomment-9965104.

@Soviut

This comment has been minimized.

Show comment
Hide comment
@Soviut

Soviut Nov 1, 2012

+1 for :extend

On Oct 31, 2012, at 7:16 PM, matthewdl notifications@github.com wrote:

@jonschlinkert https://github.com/jonschlinkert Your proposed syntax is
pretty close to what I was envisioning in my head. It feels more elegant,
and like mixin guards for LESS which mimic media query syntax, it feels
more like an extension of CSS, and therefore, more LESS-like than other
symbols.

Plus, by making :extend in the declaration, it more accurately describes
that this class definition will be merged with other selectors (and which
ones). Having the extend declaration arbitrarily placed somewhere within
the list of properties doesn't feel right for an extending behavior. This
is on par with, say, the ":not" psuedo-class, and some of the jQuery
pseudo-class extensions which mimic CSS.

Very nice work. This syntax, in itself, makes me like the whole concept of
extend even more, because it's much more clearly defined.


Reply to this email directly or view it on
GitHubhttps://github.com/cloudhead/less.js/pull/509#issuecomment-9965807.

Soviut commented Nov 1, 2012

+1 for :extend

On Oct 31, 2012, at 7:16 PM, matthewdl notifications@github.com wrote:

@jonschlinkert https://github.com/jonschlinkert Your proposed syntax is
pretty close to what I was envisioning in my head. It feels more elegant,
and like mixin guards for LESS which mimic media query syntax, it feels
more like an extension of CSS, and therefore, more LESS-like than other
symbols.

Plus, by making :extend in the declaration, it more accurately describes
that this class definition will be merged with other selectors (and which
ones). Having the extend declaration arbitrarily placed somewhere within
the list of properties doesn't feel right for an extending behavior. This
is on par with, say, the ":not" psuedo-class, and some of the jQuery
pseudo-class extensions which mimic CSS.

Very nice work. This syntax, in itself, makes me like the whole concept of
extend even more, because it's much more clearly defined.


Reply to this email directly or view it on
GitHubhttps://github.com/cloudhead/less.js/pull/509#issuecomment-9965807.

@lukeapage

This comment has been minimized.

Show comment
Hide comment
@lukeapage

lukeapage Nov 1, 2012

Member

@Soviut - when you reply in emails, click off the quote - then we get cleaner comments :)

@jonschlinkert nice. I like the idea we can use it for both stand alone and as part of the selector. some questions

  1. same as before .a, .b:extend(.c) ... does the extend cover both selectors .a and .b or should it be disallowed?
  2. is there any difference between .b :extend(.c) and .b:extend(.c) ?

If I get some time I'll look at implementing this and also figuring out how to fix #1104.. does every agree with #1104 btw? I haven't had time to figure it out.

I would love it If anyone else would prefer to do the coding, as I have plenty of other less coding to do.

Member

lukeapage commented Nov 1, 2012

@Soviut - when you reply in emails, click off the quote - then we get cleaner comments :)

@jonschlinkert nice. I like the idea we can use it for both stand alone and as part of the selector. some questions

  1. same as before .a, .b:extend(.c) ... does the extend cover both selectors .a and .b or should it be disallowed?
  2. is there any difference between .b :extend(.c) and .b:extend(.c) ?

If I get some time I'll look at implementing this and also figuring out how to fix #1104.. does every agree with #1104 btw? I haven't had time to figure it out.

I would love it If anyone else would prefer to do the coding, as I have plenty of other less coding to do.

@dpashkevich

This comment has been minimized.

Show comment
Hide comment
@dpashkevich

dpashkevich Nov 1, 2012

I like @jonschlinkert suggestion too. I wouldn't want the inheritance definition get lost among property definitions. It can still be surrounded by other pseudo-class definitions, though, but then I would probably put them on separate lines like so:

.alert
    :extend(.alert-important, .alert-danger) 
    :first-child
    :hover
    {
    background: red;
    ...
}

Of course the example is rather esoteric and in LESS I should use the & combinator nested inside the main selector instead but this syntax should still be valid, right?

One concern that I have is about pseudo-elements. The following line:

.alert::before:extend(.shiny-tip) {}

Is supposed to mean that the ::before pseudo-element extends .shiny-tip but the syntax is a bit confusing in this case.

P.S. With the Shadow DOM spec we will see way more pseudo-elements coming!

I like @jonschlinkert suggestion too. I wouldn't want the inheritance definition get lost among property definitions. It can still be surrounded by other pseudo-class definitions, though, but then I would probably put them on separate lines like so:

.alert
    :extend(.alert-important, .alert-danger) 
    :first-child
    :hover
    {
    background: red;
    ...
}

Of course the example is rather esoteric and in LESS I should use the & combinator nested inside the main selector instead but this syntax should still be valid, right?

One concern that I have is about pseudo-elements. The following line:

.alert::before:extend(.shiny-tip) {}

Is supposed to mean that the ::before pseudo-element extends .shiny-tip but the syntax is a bit confusing in this case.

P.S. With the Shadow DOM spec we will see way more pseudo-elements coming!

@lukeapage

This comment has been minimized.

Show comment
Hide comment
@lukeapage

lukeapage Nov 1, 2012

Member

Isn't it confusing allowing things after :extend? I have an idea what it
might mean, but it would mean you can extend part of a single selector? I'd
rather disallow that for now.

Member

lukeapage commented Nov 1, 2012

Isn't it confusing allowing things after :extend? I have an idea what it
might mean, but it would mean you can extend part of a single selector? I'd
rather disallow that for now.

@Soviut

This comment has been minimized.

Show comment
Hide comment
@Soviut

Soviut Nov 1, 2012

True, the :extend syntax, while CSS in spirit, deviates significantly from the SASS style @extend in terms of implementation.

Soviut commented Nov 1, 2012

True, the :extend syntax, while CSS in spirit, deviates significantly from the SASS style @extend in terms of implementation.

@lukeapage

This comment has been minimized.

Show comment
Hide comment
@lukeapage

lukeapage Nov 1, 2012

Member

Well, not necessarily but we need to think about these cases. We could
always initially just support the stand alone &:extend( first.

Member

lukeapage commented Nov 1, 2012

Well, not necessarily but we need to think about these cases. We could
always initially just support the stand alone &:extend( first.

@jonschlinkert

This comment has been minimized.

Show comment
Hide comment
@jonschlinkert

jonschlinkert Nov 2, 2012

Contributor

@agatronic the point you bring up is valid for straight CSS as well, meaning that it seems confusing. It wouldn't surprise me if a lot of front-end folks didn't know that the spec currently allows for chaining pseudo-selectors at all.

My view (conjecture?) is that if you use pseudo-selectors regularly in your CSS, then you should have very little learning curve here. As for whether or not chaining should be allowed, it seems that it would be difficult to implement without it, at least eventually. Just consider hover and active as prime examples. I think if we view the problem from 20,000 feet, we shouldn't allow the syntax to determine the objective.

It makes the most sense to consider the following as a typical use-case, and a reason to allow chaining:

E:hover:extend(...) {}

We make regular use of these pseudo-selectors:

E:hover {}
E:active {}
E:before {}
E:after {}

So my suggestion is to think if it in that context, rather than thinking of more complicated and less-often used use cases like:

p:first-child:first-letter:first-line:after:hover {}

Which, btw, is valid. But would anyone use it? I guess, yeah, sure if I had to... but it's not a probably not a good use case lol.

That being said, I'm aware that you have to weigh this against other considerations, so it's ultimately up to you whether or not chaining will be introduced in the first iteration of the :extend feature.

My vote is that :extend is still powerful without chaining, but even more useful with it. So do whatever is pragmatic for now..

Contributor

jonschlinkert commented Nov 2, 2012

@agatronic the point you bring up is valid for straight CSS as well, meaning that it seems confusing. It wouldn't surprise me if a lot of front-end folks didn't know that the spec currently allows for chaining pseudo-selectors at all.

My view (conjecture?) is that if you use pseudo-selectors regularly in your CSS, then you should have very little learning curve here. As for whether or not chaining should be allowed, it seems that it would be difficult to implement without it, at least eventually. Just consider hover and active as prime examples. I think if we view the problem from 20,000 feet, we shouldn't allow the syntax to determine the objective.

It makes the most sense to consider the following as a typical use-case, and a reason to allow chaining:

E:hover:extend(...) {}

We make regular use of these pseudo-selectors:

E:hover {}
E:active {}
E:before {}
E:after {}

So my suggestion is to think if it in that context, rather than thinking of more complicated and less-often used use cases like:

p:first-child:first-letter:first-line:after:hover {}

Which, btw, is valid. But would anyone use it? I guess, yeah, sure if I had to... but it's not a probably not a good use case lol.

That being said, I'm aware that you have to weigh this against other considerations, so it's ultimately up to you whether or not chaining will be introduced in the first iteration of the :extend feature.

My vote is that :extend is still powerful without chaining, but even more useful with it. So do whatever is pragmatic for now..

@lukeapage

This comment has been minimized.

Show comment
Hide comment
@lukeapage

lukeapage Nov 2, 2012

Member

It wasn't chaining that I was concerned with.. it was having the extend in
the middle of the selector.. does it still apply to the whole thing?

Member

lukeapage commented Nov 2, 2012

It wasn't chaining that I was concerned with.. it was having the extend in
the middle of the selector.. does it still apply to the whole thing?

@matthew-dean

This comment has been minimized.

Show comment
Hide comment
@matthew-dean

matthew-dean Nov 5, 2012

Member

To jump in, no, I don't think :extend should be allowed in the middle of the selector. Like jQuery's extensions, it still belongs at the end. It should apply to the entire selector as a string match.

To extend a block like above:

E:hover:extend(...), E:active:extend(...) {
  property: value;
}

// equivalent to:

E:hover, E:active {
  &:extend(...) {
    property: value;
  }
}

This allows you to separate and use LESS in coherent blocks, extending only the properties you want to base classes, while having some properties only be local one-off values, or controlling output order.

E:hover, E:active {
  &:extend(...) {
    property: value;
  }
  non-merged-property: value;
}

In other words, this syntax I think would be simpler to understand and also a bit more powerful than SASS.

Member

matthew-dean commented Nov 5, 2012

To jump in, no, I don't think :extend should be allowed in the middle of the selector. Like jQuery's extensions, it still belongs at the end. It should apply to the entire selector as a string match.

To extend a block like above:

E:hover:extend(...), E:active:extend(...) {
  property: value;
}

// equivalent to:

E:hover, E:active {
  &:extend(...) {
    property: value;
  }
}

This allows you to separate and use LESS in coherent blocks, extending only the properties you want to base classes, while having some properties only be local one-off values, or controlling output order.

E:hover, E:active {
  &:extend(...) {
    property: value;
  }
  non-merged-property: value;
}

In other words, this syntax I think would be simpler to understand and also a bit more powerful than SASS.

@lukeapage

This comment has been minimized.

Show comment
Hide comment
@lukeapage

lukeapage Nov 5, 2012

Member

Sounds good.

Member

lukeapage commented Nov 5, 2012

Sounds good.

@jonschlinkert

This comment has been minimized.

Show comment
Hide comment
@jonschlinkert

jonschlinkert Nov 11, 2012

Contributor

I've had some time to test :extend in 1_4_0 (using the default test files as well as Bootstrap's Less), and so far it works as expected. Lot's more testing to do, but I'm also looking forward to seeing feedback from others. Thanks for the hard work on this!

Contributor

jonschlinkert commented Nov 11, 2012

I've had some time to test :extend in 1_4_0 (using the default test files as well as Bootstrap's Less), and so far it works as expected. Lot's more testing to do, but I'm also looking forward to seeing feedback from others. Thanks for the hard work on this!

@Synchro

This comment has been minimized.

Show comment
Hide comment
@Synchro

Synchro Nov 11, 2012

Member

It would be much appreciated if you could contribute some examples and edge cases to add to the tests.

Member

Synchro commented Nov 11, 2012

It would be much appreciated if you could contribute some examples and edge cases to add to the tests.

@jonschlinkert

This comment has been minimized.

Show comment
Hide comment
@jonschlinkert

jonschlinkert Nov 13, 2012

Contributor

@Synchro no problem, I'd be happy to. I'll try to put something together this week.

Contributor

jonschlinkert commented Nov 13, 2012

@Synchro no problem, I'd be happy to. I'll try to put something together this week.

@lukeapage

This comment has been minimized.

Show comment
Hide comment
@lukeapage

lukeapage Nov 13, 2012

Member

Check the existing tests.. there are a number already.

Would appreciate any comments on whether less should copy the selector
matching of sass or keep things simple. See the bug I referenced above.

I've still yet to expand it to allow using extend in the selector..

One question on the stand alone...

.b {
  &:extend(.a);
}

Or

.b {
  :extend(.a);
}

Or both?

Member

lukeapage commented Nov 13, 2012

Check the existing tests.. there are a number already.

Would appreciate any comments on whether less should copy the selector
matching of sass or keep things simple. See the bug I referenced above.

I've still yet to expand it to allow using extend in the selector..

One question on the stand alone...

.b {
  &:extend(.a);
}

Or

.b {
  :extend(.a);
}

Or both?

@jonschlinkert

This comment has been minimized.

Show comment
Hide comment
@jonschlinkert

jonschlinkert Nov 13, 2012

Contributor

I think only the first example should be valid. &:extend conforms to a known pattern in Less

Contributor

jonschlinkert commented Nov 13, 2012

I think only the first example should be valid. &:extend conforms to a known pattern in Less

@Soviut

This comment has been minimized.

Show comment
Hide comment
@Soviut

Soviut Nov 13, 2012

I agree. It should follow the correct selector logic if it's going to be treated as a pseudo-selector. The first example reads as "extend .b with .a" while the second example reads as "extend the decendents of .b".

Soviut commented Nov 13, 2012

I agree. It should follow the correct selector logic if it's going to be treated as a pseudo-selector. The first example reads as "extend .b with .a" while the second example reads as "extend the decendents of .b".

@matthew-dean

This comment has been minimized.

Show comment
Hide comment
Member

matthew-dean commented Nov 13, 2012

@Soviut

This comment has been minimized.

Show comment
Hide comment
@Soviut

Soviut Nov 13, 2012

Documentation-wise, I think the .b:extends(.a) syntax should be pushed more prominently though.

Soviut commented Nov 13, 2012

Documentation-wise, I think the .b:extends(.a) syntax should be pushed more prominently though.

@matthew-dean

This comment has been minimized.

Show comment
Hide comment
@matthew-dean

matthew-dean Nov 13, 2012

Member

@Soviut +1 to that, too.

Member

matthew-dean commented Nov 13, 2012

@Soviut +1 to that, too.

@jonschlinkert

This comment has been minimized.

Show comment
Hide comment
@jonschlinkert

jonschlinkert Nov 15, 2012

Contributor

@agatronic and forgot to mention, no problem on the tests either way. I did run the tests included in 1_4_0, everything checks out. If you want me to throw more together as 1_4_0 progresses just say the word

Contributor

jonschlinkert commented Nov 15, 2012

@agatronic and forgot to mention, no problem on the tests either way. I did run the tests included in 1_4_0, everything checks out. If you want me to throw more together as 1_4_0 progresses just say the word

@lukeapage

This comment has been minimized.

Show comment
Hide comment
@lukeapage

lukeapage Nov 16, 2012

Member

this is the bug I would appreciate comments on

#1014

Member

lukeapage commented Nov 16, 2012

this is the bug I would appreciate comments on

#1014

@jonschlinkert

This comment has been minimized.

Show comment
Hide comment
@jonschlinkert

jonschlinkert Nov 16, 2012

Contributor

@agatronic will do, I'm putting something together since there is some thought involved here. I'll update as soon as I have something to share.

Contributor

jonschlinkert commented Nov 16, 2012

@agatronic will do, I'm putting something together since there is some thought involved here. I'll update as soon as I have something to share.

@feichang

This comment has been minimized.

Show comment
Hide comment
@feichang

feichang Dec 25, 2012

+1 for extend

+1 for extend

@czarnota

This comment has been minimized.

Show comment
Hide comment
@czarnota

czarnota Jan 5, 2013

why not to just steal @extend syntax from SASS?

czarnota commented Jan 5, 2013

why not to just steal @extend syntax from SASS?

@lukeapage

This comment has been minimized.

Show comment
Hide comment
@lukeapage

lukeapage Jan 5, 2013

Member

Because sass has a different design philosophy. We have already decided the
syntax.

Member

lukeapage commented Jan 5, 2013

Because sass has a different design philosophy. We have already decided the
syntax.

@DesignByOnyx

This comment has been minimized.

Show comment
Hide comment
@DesignByOnyx

DesignByOnyx Jan 25, 2013

I have finally gotten around to testing this and wanted to post my initial findings. I have been using the alpha version less-1.4.0-alpha.js on the client-side only (no command line yet - not that it should be any different really).

So far, everything works as I would expect except for two major drawbacks which can be explained with one example. Take the following code which is located in one of my root LESS files:

.container { margin: 0 auto; }
.container.positioned { position: absolute }

@media screen and (min-width: 30rem) {
    .container.positioned { left: 50%; }
}
@media screen and (min-width: 30rem) and (max-width: 48rem) {
    .container { width: 30rem; }
    .container.positioned { margin-left: -15rem; }
}
@media screen and (min-width: 48rem) and (max-width: 60rem) {
    .container { width: 48rem; }
    .container.positioned { margin-left: -24rem; }
}
@media screen and (min-width: 60rem) {
    .container { width: 60rem; }
    .container.positioned { margin-left: -30rem; }
}

Issue 1 - styles defined within media queries do not get extended. Anything trying to extend the .container class only gets the margin: 0 auto styles.

.some-element:extend(.container);

Issue 2 - compound selectors do not get extended. However, the first participant DOES get extended. For example, the following incorrectly extends the .container styles but not the intended .container.positioned styles.

.some-element:extend(.container.positioned);

I wish I could provide a solution. Hope this helps.

I have finally gotten around to testing this and wanted to post my initial findings. I have been using the alpha version less-1.4.0-alpha.js on the client-side only (no command line yet - not that it should be any different really).

So far, everything works as I would expect except for two major drawbacks which can be explained with one example. Take the following code which is located in one of my root LESS files:

.container { margin: 0 auto; }
.container.positioned { position: absolute }

@media screen and (min-width: 30rem) {
    .container.positioned { left: 50%; }
}
@media screen and (min-width: 30rem) and (max-width: 48rem) {
    .container { width: 30rem; }
    .container.positioned { margin-left: -15rem; }
}
@media screen and (min-width: 48rem) and (max-width: 60rem) {
    .container { width: 48rem; }
    .container.positioned { margin-left: -24rem; }
}
@media screen and (min-width: 60rem) {
    .container { width: 60rem; }
    .container.positioned { margin-left: -30rem; }
}

Issue 1 - styles defined within media queries do not get extended. Anything trying to extend the .container class only gets the margin: 0 auto styles.

.some-element:extend(.container);

Issue 2 - compound selectors do not get extended. However, the first participant DOES get extended. For example, the following incorrectly extends the .container styles but not the intended .container.positioned styles.

.some-element:extend(.container.positioned);

I wish I could provide a solution. Hope this helps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment