:extend from ruleset variables

[Justineo]

As discussed in #1177, we can implement "abstract extends" like Sass's placeholders if mixins can be extended.

Now we have ruleset variables since 1.7.0 and what do you guys think if we use that rather than mixins? Then mixins keep's their current usage and ruleset variables can act like some "abstract" parent styles.

Like this:

@item: {
  .clearfix();
  // other stuff
};

.a:extend(@item);

// ...

.b:extend(@item);

which gives us:

.a,
.b {
  /* clearfix stuff and other */
}

[Justineo]

Actually I think DRs already work as mixins without parameters. Mixin and extend are two different methods to reuse styles so extending mixins might make it a little frustrating.

When we talk about mixins we clearly know rules will be copied into current scope while by extending we combine selectors into a group.

So extending a "ruleset" makes more sense in my opinion.

[matthew-dean]

I'd prefer to extend DRs rather than mixins, because they feel more like logical "templates" to extend. But of course I think extending mixins is valuable too. So, like @Justineo, it's more a matter of what feels natural in this case.

[calvinjuarez]

This is a super interesting idea. If the question is what feels more natural, though, I think I'd still have to go with mixins; they more closely resemble the selector{ruleset} syntax (vs. property:value;) which the extend syntax pattern—:extend(selector)—seems to favor. Especially since the selector{ruleset} → mixin{ruleset} parallel has been a part of Less from the beginning.

So that's my 2¢.

---

Other things to consider:

• It seems that many folks want to be able to extend mixins with passed parameters. Extending DRs wouldn't allow this in the same way (see example below).
• Choosing to extend rulesets over mixins would resolve the questions about how to handle mixins with parameters, so things might could move ahead more quickly.

Example

.mixin(parameters) { rules: here; }
.selector { &:extend(.mixin(parameters)); }  // mo' power, mo' problems

// VS.

.mixin(parameters) { rules: here; }
@ruleset: { .mixin(parameters); };
.selector { &:extend(@ruleset); }

[matthew-dean]

Detached rulesets are kind of odd beasts. They very nearly resemble mixins with just enough slight variation to cause developer errors. But that's a different issue. But yes, good ideas here.

[lukeapage]

I think its weird because you are turning a variable definition (of a ruleset) into a ruleset. Also what if we want a format to extend a selector in a variable? What happens with multiple vars or if you have a var with the same name that isnt a dr? I dont think extending mixins is that much harder.. we talked about a first stage for that where it only worked with mixins without params.

[matthew-dean]

what if we want a format to extend a selector in a variable?

That seems wholly unnecessary, but it doesn't seem insurmountable, as we've discussed namespaced referencing of properties / variables elsewhere and formats for those.

@tables: {
  table {
   table-layout: fixed;
  }
};
.table1:extend(@{tables > table} all) {}
// or .table1:extend(${@tables > table} all) {}
// or .table1:extend(@tables > table all) {}

Still, not sure why someone would want to do that.

What happens with multiple vars or if you have a var with the same name that isnt a dr?

The same thing that happens now. You can't run a color function on two vars of the same name if the final value is not a color.

I dont think extending mixins is that much harder.

I don't think doing one precludes doing the other. Both make sense to me for different reasons, and yes, mixins could be done in stages.

[seven-phases-max]

@matthew-dean

I guess he means #1485 feature. Indeed there's possible syntax conflict.

---

(Not counting syntax problems (if any)) I think this is a pure matter of personal preferences to prefer one or another (half joking mode on: indeed some people do afraid of mixins while others (e.g. me) prefer to use a DR only where a use-case requires DR's variable-like semantics).
I can't see any reason to vote against this on its own, but sure, absolutely not as a replacement for #1177.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.