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).

[matthew-dean]

Partial duplicate of #1342, which, obviously, I think is an awesome idea. ;-) The "downside" that you can't tell that the rule does something magic, to me, is somewhat silly. The developer wrote it. The developer knows what's going to happen. It's like saying it's not obvious that a statement is finished in JavaScript if you don't type a semi-colon. Maaybe, but uhhh...

The upside is aesthetics. CSS-like syntax just looks sexier than mixin syntax. Starting calls with a period is somewhat ugly, and parentheses aren't always needed. Obviously that's a preference like tabs vs. spaces, or CoffeeScript instead of JavaScript, but both preferences are valid.

The other reason not listed here is that you could auto-prefix silently, and unprefix when there is browser support by adjusting your mixins. Powerful stuff.

I wish there was more activity on this, or on #1342 but I understand there's not universal support.

[lukeapage]

The developer wrote it. The developer knows what's going to happen

A developer wrote it. Another developer may well be reading it.

[matthew-dean]

Another developer may well be reading it.

True. I worked with a developer who defined a variable with a single Δ. It's technically a legal character in JavaScript, and the fact that it's legal is fine, and the fact that it's legal did not make the developer make stupid decisions. The developer made stupid decisions. Having more powerful options does make developers more stupid, and we don't have to save them from themselves.

I get your point that it's not as self-documenting as a mixin reference, but I feel that not every feature has to be fully self-documenting. For instance, in JavaScript, every piece of the language can be redefined. Some developers hate that and some abuse it, but there are some instances where transparently extending the language makes sense for your project, and can make your code cleaner and easier to manage. I'm arguing for the same here.

[lukeapage]

my point is that why introduce a feature that is likely to create abused code for the sole reason to make the less look pretty. I don't see any use-cases where this would make css more maintainable.

[matthew-dean]

One use case: Transparent prefixing. We have a pile of issues of people trying to autoprefix or having to run code through auto-prefixes, which has it's own additional issues, especially if it comes to source maps. It's a common approach in JavaScript. You shim the language rather than change the language to code it one way, and then when support is added, you have to go back and unshim all your calls. Polyfilling is a standard practice in many instances.

I've found myself often having to rewrite a number of lines based on the fact the mixin is no longer necessary. I don't deny there are possibilities for abuse. But I would contend that the way we do it now is inherently less maintainable for this particular use case. When support for the unprefixed property is added by enough browsers, you can't just delete the mixin, you either have to search/replace all references to the mixin and rewrite it with the unprefixed value, or you would delete most of the contents of the mixin except for the unprefixed one. This is just one use case, but you can't tell me this is not a valid CSS problem.

[matthew-dean]

Another use case: Property grouping.

There are instances where a CSS property only really has any effect when paired with another property. Declaring one property could auto-fill the property needed, without code redundancy.

[matthew-dean]

Another use case: Legacy support

There are instances where an additional CSS property is needed when using one property in order to make Internet Explorer behave.

[matthew-dean]

I'll concede that this is but one solution to these use cases, and there may be a more elegant one, but these are typical things I've encountered where I've wished to make Less smarter, reduce redundancy, and increase maintainability. For some specific use cases, I find Less makes your code more obscure and harder to manage than its CSS counterpart, and this is one of them.

[matthew-dean]

Again, if it's the wrong syntax, let's talk about that. But polyfilling is a powerful feature, addresses real use cases, and just one possibility by allowing property definitions.

[lukeapage]

I would love transparent prefixing. I want to do that with a plugin - In fact I already wrote a plugin for it over on the less-plugins repo, but it needs extending. Since prefixes are slowly being removed from major browsers, I don't think we should add (more) language features for it (property interpolation being the other one).

The other 2 cases are cases that could be fullfilled with plugins, but you could argue are an important part of the less. In both those cases I'd prefer (in projects I am part of) that people use mixins for those cases so that its explicit what is going on (I can guess you might add a smart property and then find there is an exception and then define a new property... all you are doing is descrbing an alternative syntax for mixins, but without all the power we already have with mixins like for instance guards etc.)

[Soviut]

I feel that autoprefixer is a better solution to the vendor prefix issue when compiling server-side. Additionally, there are several prefixing javascript libraries that do something similar in the browser. The only thing that would be an issue is shuttling the dynamically generated css from less through a prefixer in the browser. That's still far simpler than trying to build prefixing systems into less.

I think any auto-prefixing should be something handled by a plugin system with hook for post-processing.

[seven-phases-max]

(Yeah, the other day I was thinking about winning a galactic elections with the "CSS preprocessors are for Styles not for Prefixes!" slogan.)

[matthew-dean]

True. In about a year prefixes will be mostly gone for the things we use today, and with how much they've fallen out of favor, I doubt they'll ever occur in quite the numbers we saw in the transition to CSS3. Still.... that doesn't mean NO prefixing. Hmm....

[matthew-dean]

@lukeapage If we can have a robust and flexible enough API to do this with plugins (and plugins will get auto-loaded), then that sounds perfect.

[jonschlinkert]

If we can have a robust and flexible enough API to do this with plugins (and plugins will get auto-loaded), then that sounds perfect.

Amen! starting with a clean and straightforward API would be great.

[matthew-dean]

@jonschlinkert I had asked elsewhere (I forget where) where we might start sketching out and planning/ documenting a Less API. A wiki page somewhere? Which repo?

[jonschlinkert]

@matthew-dean I'm not sure. unless @lukeapage has a different preference, maybe a good place to start would be to have a dedicated issue here on Less.js: focus would be general discussion, goals, use cases, etc.

we can also carve out a place where we can actually push up some code/pseudo-code just to give us have something more tangible and coherent to think over, get feedback and contributions from the community, etc. seems like a temporary repo would be easier to work with than the wiki. @lukeapage what are your thoughts?

[Soviut]

Done #1861

That issue can now be considered the official API for plugins thread.