Creating own rules [sugar]

[dangreen]

What about this feature?
Example:

@rule box(@width, @height: @width) { // or +box(@width, @height: @width) or another prefix symbol
    width: @width;
    height: @height;
}
// usage
.block { box: 10px } // width: 10px; height: 10px;
.search { box: 100px 10px } // width: 100px; height: 10px;

[Soviut]

This seems interesting, but deviates so little from the standard mixin syntax I don't really see the benefit. Is writing the following so much more difficult?

.block { box(10px); }

If there were significant gains to having an "exploded" mixin syntax like this, I'd be all for it. But other than removing a bracket or two, I don't see this as being sweet enough to be called syntactic sugar. Especially since this could add additional confusion when approaching an unfamiliar LESS sheet and seeing what look like custom arguments used as mixins.

[dangreen]

I know that mixins exists ( .block { box(10px); } ), but for me it looks like a foreign. "my" syntax more "native".
For me it would be interesting to have this syntax.

[Soviut]

I don't disagree, but interesting is one thing, useful is another. I actually find mixins with parentheses easier to identify than ones without, and even requested they be mandatory in future versions for clarity. While your suggestion certainly makes things feel even more css-like, it can also be confusing.

For example, what happens if rule is created that conflicts with a native css attribute?

[dangreen]

For example, what happens if rule is created that conflicts with a native css attribute?

Return exception error ;-)

[Soviut]

That would mean all native attributes would need to be tracked in order to detect said conflicts. This becomes even more difficult when you consider vendor prefixes as well as experimental attributes that are only part of proposed specifications but may still have limited support.

[dangreen]

OK, use prefixes:

-less-box: 50px; // or another prefix

[Soviut]

What if somebody makes a browser called LESS? ;) I'm kidding, however, you've just lost most of the benefit of your syntactic sugar at that point.

[dangreen]

I don't think what realize this feature too hard. Why not make this function test and give to people use it?

[dangreen]

OR, use mixing syntax but with some sugar?

.box(@width, @height: @width) { // standard mixin
    width: @width;
    height: @height;
}
// usage
.block { .box: 10px } 
.search { .box: 100px 10px } 

agree... it is quite close to the standard mixins.

[Soviut]

I agree, why don't you create a fork and try to implement it. ;) I'm not disagreeing that the syntactic sugar is nice, but you need to consider the pitfalls before implementing a feature. If you can do that in your own branch then by all means, do so then send a pull request.

[dangreen]

okay )

[Soviut]

Okay, mixins without parentheses might be a little more manageable. Still, at this point, you've eliminated the brackets and little else.

I feel compelled to ask if there's anything beyond the sugar that you can justify this being useful for? Especially since nesting mixins/rules is going to be really difficult (see CoffeeScript for similar multi-param issues).

[Soviut]

That said, please don't let me discourage you! If you want to attempt an implementation, please do so. I'm just challenging you to consider the edge cases.

[lukeapage]

I don't see the benefit of this syntax. I think something similar has been suggested before and the downside was that you can't tell that a rule is actually going to do something magic.. with a mixin you see where it is invocated.

So, thanks for the suggestion, but I would suggest closing this one.

[seven-phases-max]

Closed due to inactivity (and as duplicate of #1342).