Expand Mixin definitions

[matthew-dean]

Update Apr 26, 2015 - with some more familiarity with the language and parser, I'm dropping the second part of the proposal. I still think it's a valid question about allowing the author to use the three most common selector forms as mixins.

Update on my update from 2 seconds ago. I realized that the remainder of the proposal Leads to ambiguity with the proposal for accessing namespaced properties. (#1848) So fuck it, closing.

---

I have a proposal for some expansion of mixin syntax that might make usage a bit easier.

Drop the dot notation requirement

It seems somewhat arbitrary that mixins need to start with a dot. They're not really a class selector, nor used as one. It seems like I should just be able to do this.

my-mixin(@var) {
  // mixin stuff
}
.one {
  my-mixin(red);
}

Allow mixin "assignment"

Many times, when I've changed a CSS3 property to a CSS3 mixin, I have to adjust not just the property name but the way in which the value is declared.

I add parentheses, my code coloring changes, it feels somewhat inelegant. It would be much quicker if I could do this:

my-box-shadow(@shadow) {
  -moz-box-shadow: @shadow;
  box-shadow: @shadow;  
}
.box {
  my-box-shadow: @shadow;
}

The entire value (between the colon and the semi-colon) is passed to a mixin with a single variable declaration, even if that value has commas. (This would only work for mixins with only one variable, but could work quite elegantly.) It makes LESS feel even more like an extension of CSS.

Now, for the magic secret sauce, where these ideas can be even more powerful.

By doing things this way, you can expand write mixins that gracefully support CSS3 properties. In other words, you don't have to re-write anything. You could just install a mixin library.

Observe:

box-shadow(@shadow) {
  -moz-box-shadow: @shadow;
  box-shadow: @shadow;
}
.box {
  box-shadow: 1px 2px black;
}

// Outputs

.box {
  -moz-box-shadow: 1px 2px black;
  box-shadow: 1px 2px black;
}

If the author makes a mistake and also includes the prefix version, I believe we have a current pull request to collapse those properties anyway, making the CSS the same size.

The last usage is not the only goal, as I think un-dotted mixins and mixin assignment is a good idea on its own merit.

[lukeapage]

In positive cases it looks good.

I don't like that it isn't obvious you are essentially calling a mixin.. I think on larger projects or without due care, this could result in less that is hard to debug.

Interested to hear a few more opinions

[matthew-dean]

The only reason dot notation is recognized as a mixin is convention. In Less, a mixin with no parameters and a CSS class are essentially identical, so they're invisible as it is. We already kinda have that weirdness. It would just treat CSS elements the same way.

In practice, though, mixins typically have parentheses, so they're not really confused with style definitions.

[lukeapage]

The only reason dot notation is recognized as a mixin is convention. In Less, a mixin with no parameters and a CSS class are essentially identical, so they're invisible as it is. We already kinda have that weirdness. It would just treat CSS elements the same way.

In practice, though, mixins typically have parentheses, so they're not really confused with style definitions.

my previous response was about the second part of the proposal.

In terms of removing the dot or hash requirement the only confusion would be between mixins and function calls - but I'm less concerned about that.

[seven-phases-max]

Btw., nice idea but I suspect this would be a nightmare from the performance point of view. Because we will have to search for mixin match for every property.

[matthew-dean]

@seven-phases-max That to me is a stronger side of the argument. But don't we match keywords, interpolate variables, etc for all parts of the property/value statement? That is, we already have to parse and decide what things are, so I would think we would just be deciding it's something different, no? We would already have to decide that the first part of the statement is a mixin if we dropped the dot requirement, so we'd already be matching / looking up for the same length of characters, theoretically.

[seven-phases-max]

But don't we match keywords, interpolate variables, etc for all parts of the property/value statement?

We do but only when nesessary, e.g.:

@{width}: @var; // yes, we're searching for vars here
width: 1px; // don't have to search for anything
.mixin(); // searching for the mixin

So only explicit interpolations, mixin calls etc. affect perfomance.
With this new concept:

width: 1px; // always search for a mixin first

If I'm not mistaken searching for mixin match is one of the slowest procedures (only searching for extend match is slower :)

P.S. I was a bit frightened to see oyejorge/less.php#60 (comment). Less.js is faster but I guess the relative timings of the corresponding compiler sub-routines are similar.

[matthew-dean]

Hmm.... interesting....

[matthew-dean]

Closing under the categories of "probably a bad idea" and "conflicts with better proposals".