Support strings as property names

[mrcljx]

This is analogous to the recent 93b23d2 (support strings as selectors) commit.

Includes a regression test.

This fixes #36 and should make creating vendor-aware libraries/mixins much easier. An example where this could be useful:

.experimental(@property, @value) {
  ~"-webkit-@{property}": @value;
  ~"-moz-@{property}": @value;
  ~"-ms-@{property}": @value;
  ~"-o-@{property}": @value;
  ~"@{property}": @value;
}

.borderRadius(@value) {
  .experimental("border-radius", @value);
}

article {
  .borderRadius(5px);
}

// CSS OUTPUT

article {
  -webkit-border-radius: 5px;
  -moz-border-radius: 5px;
  -ms-border-radius: 5px;
  -o-border-radius: 5px;
  border-radius: 5px;
}

Also it should make @metaskills (see blogpost) happy. 🎁

[stefanpearson]

This would be very useful to me. I want to be able to use the rem unit with a pixel fallback for any property. For example:

.remify(@Property, @value) {
@Rem: (@value / 10);
~"@{property}": @value * 1px;
~"@{property}": ~"@{rem}rem";
}

[metaskills]

Should be closed? My understanding is that 1.3 added this feature?

[metaskills]

This is the commit 93b23d2 that added it and referenced in my updated blog post.

[mrcljx]

Nope, 93b23d2 added support for selectors (~".span@{n}") { color: red; } while this commit also allows them on properties ~"@{property}": red;.

However @cloudhead made it clear that he doesn't like 93b23d2 to begin with (being too much a preprocessing feature and breaking the language design). Thus I expect him not to merge this pull-request and rather reject/close it.

In the end that depends on which direction less.js will take with 1.4.

[metaskills]

Wow :(

[stefanpearson]

That's a shame. A perfect use case would be

.selector {
.rem("margin-bottom", 10);
}

CSS -

.selector {
Margin-bottom: 10px;
Margin-bottom: 1rem;
}

[remoun]

I didn't know I could be used as a unit...

This looks cool, though. :-)

[Akkuma]

If features like this don't make it into the core, isn't it only a matter of time someone forks it with the intent of allowing all preprocessor features?

[nadersoliman]

I like it ... thumbs up sirlantis

[jmgunn87]

This would/will solve this problem using IMO a more in keeping syntax => #790

[borodean]

I've made a set of mixins to workaround this issue: https://github.com/borodean/less-properties

It works like this:

@property: border-radius;
.class {
  .property(@property, 10px);
}

Which will output in:

.class {
  -less-property: property;
  border-radius: 10px;
}

Or even this:

.class {
  .property(border-radius, 10px, 'moz webkit o');
}

Which outputs in:

.class {
  -less-property: property;
  -moz-border-radius: 10px;
  -webkit-border-radius: 10px;
  -o-border-radius: 10px;
}

I would appreciate any help for developing this set further.

[rentalhost]

+1

[lucas-clemente]

+1

[jmgunn87]

#790

[lazd]

Either this or #790 would help LESS to be more DRY. Even Twitter Bootstrap is stuck repeating itself over and over because there is just simply no decent way to do what needs to be done:

.rotate(@degrees) {
  -webkit-transform: rotate(@degrees);
     -moz-transform: rotate(@degrees);
      -ms-transform: rotate(@degrees);
       -o-transform: rotate(@degrees);
          transform: rotate(@degrees);
}
.scale(@ratio) {
  -webkit-transform: scale(@ratio);
     -moz-transform: scale(@ratio);
      -ms-transform: scale(@ratio);
       -o-transform: scale(@ratio);
          transform: scale(@ratio);
}

I believe that this is one of the language features that is holding LESS back from having a complete set of CSS3 mixins like Compass.

[mrcljx]

@sashasklar @cloudhead Could you add an opinion on this issue? Is that something that you object to have in LESS? I understand your concert that this adds a macro-like mechanism to the language, however it's use is restricted and useful (see examples from above).

[sturobson]

Although a nice idea this shouldn't be implemented because adding prefixes carte blanche will add bloat to your code. Not every CSS3 element has had all the prefixes all the time. So adding them all to something would be a bad thing to do.

[mrcljx]

@sturobson This pull-request only allows the ~"@{foo}": @value; syntax and isn't a recommendation for .experimental mixin (which is just one of the multitude of use-cases).

Whether or not to add and an .experimental-mixin is up to developers of libraries/frameworks building upon less like bootstrap.

[jmgunn87]

Personally the syntax is ugly with this fix. #790 will be alot easier to follow imo

[mrcljx]

@jmgunn87 This pull-request isn't about assigning variables, it's about allowing variables on the left-hand side of property rules. #790 solves a different problem.

[jmgunn87]

no it doesn't. read it carefully. it is exactly the same as php's variable variable syntax. This is for having variable property names, not variable values.

[mrcljx]

#790 is about writing dynamically to a variable through another variable (variable variable names). The PHP equivalent: $$foo = $value;.

~"@{foo}": @value; from this pull-request outputs a CSS rule (and doesn't set a variable). The PHP equivalent: echo $foo.": ".$value;.

[jmgunn87]

you can do the same thing. I've tried it. I will write a use case to show an example

[ice-horse]

I was looking for a feature like that and hope it will be implemented soon. Would save a lot of time just being able to use the following instead of declaring mixins for every single CSS3 property:

.prefixify(@property,@params) {...}

[matthew-dean]

I agree that this is pointing to a real problem: Having to repeat prefixes.

Is this the most elegant solution? Not sure. It is a solution, but the escaped string syntax always looks messy to me.

In addition, prefixing often looks similar, but not all prefixes are needed in every case. Some things get finalized (non-prefixed) in a browser before others, meaning that you would have to override / add prefixes in specific cases anyway.... meaning abstracting a "prefixing" function doesn't really make sense.

So....

[lukeapage]

Assuming I get my pull request to have selectors like this

.@{variable}-1 {
}

then the obvious extension is to use this for property names

-webkit-@{property}: my-stuff;

in dotless I was thinking of writing a plugin that replaced all property names ending in -all-browsers with duplicates for every browser prefix. e.g.

-all-browsers-X: Y;

becomes

-ms-X: Y;
-webkit-X: Y

etc.

So another question.. what uses does prefix interpolation have outside of prefixing of browser properties?

[lukeapage]

alternate idea for prefixes

#1199

only remaining case is this

.selector {
  .rem("margin-bottom", 10);
}

==>

.selector {
  margin-bottom: 10px;
  margin-bottom: 1rem;
}

which I'm not sure I like.. its a good abstraction, but yeh, not sure about it.

[demoive]

Here's my solution to this problem: vendorify.less.

It was inspired by @borodean's solution, but from his test cases noticed it had a bug. For example, you can't pass in values with spaces nor does it support comma-separated compound values - which would be needed for things such as multiple backgrounds, and gradients, etc.) When I started going through his code to find a fix, I created what I think is a more simple solution to the same idea. Sure, it won't allow you to change which vendor prefixes get used (unless you modify the actual mixin), but how often do you need to specify different vendor prefixes within the same project?

Checkout the test cases in the comments below my vendorify.less Gist. It is quite extensive allowing you to specify values with spaces:

/* LESS */
.style {
  .vendorify(border-radius, 5px 10px);
}

/* CSS Output */
.style {
  -less-vendorify: ;
  -o-border-radius: 5px 10px;
  -ms-border-radius: 5px 10px;
  -moz-border-radius: 5px 10px;
  -webkit-border-radius: 5px 10px;
  border-radius: 5px 10px;
}

and even compound values:

/* LESS */
.style {
  .vendorify(background, url(bg2.png) repeat, url(bg3.png) no-repeat);
}

/* CSS Output */
.style {
  -less-vendorify: ;
  -o-background: url(bg2.png) repeat, url(bg3.png) no-repeat;
  -ms-background: url(bg2.png) repeat, url(bg3.png) no-repeat;
  -moz-background: url(bg2.png) repeat, url(bg3.png) no-repeat;
  -webkit-background: url(bg2.png) repeat, url(bg3.png) no-repeat;
  background: url(bg2.png) repeat, url(bg3.png) no-repeat;
}

[matthew-dean]

So another question.. what uses does prefix interpolation have outside of prefixing of browser properties?

It's a good question. If it has none, then, like other similar issues, the syntax and problem should be focused on just the most elegant solution for that.

But.... I could see someone doing this?

.attach-red-border(@position) {
  border-@{position}: 4px solid red;
}

Seems weird, but rather than the theoretical, it's worth input on that point. Are people wanting this only for prefixes?

[jonschlinkert]

I've said this several times, the CSS spec is introducing custom properties, variable property names is a must-have that should be high on or priority list. Vendor prefixes is a convenient example (and not very compelling), but it's not the only use for custom properties.

[matthew-dean]

Right. Even if it was only for prefixes, it still seems valuable to let the stylesheet author swap in property names. It seems like an intuitive addition. Let's do this, based on @lukeapage's syntax.

[jonschlinkert]

Which one? He's mentioned a couple, you probably mean @{variable}, so it's consistent with selector interpolation? If so I'm in agreement. The other one that comes to mind was geared towards the prefixes: -*-, so I'm guessing that's not the one you meant

[matthew-dean]

Yes (to the first point). This seems like an easy win:

-moz-@{myvar}: value;

[Soviut]

Agreed. Variable interpolation within property names is a no-brainer. +1 for the border-@{attr}: value syntax.

[jonschlinkert]

Maybe this is implied, but to be clear the syntax should allow the entire property name to be interpolated:

@{prop}: value

And since values can already be variables:

@{prop}: @value;

[Soviut]

Again, agreed. There are plenty of situations where this would be handy, and just as many places it would be critical to work with mixins.

[jonschlinkert]

just as many places it would be critical to work with mixins.

Agreed. I think we don't take that for granted as often as we should.

[xxaff]

+1

[dwt]

+1 Any way to write a generic and clean .vendorize is required - I actually don't care which.

I want something that allows me to generate vendor prefixes without the repetition, and allows me to override specific vendor names if they differ.

[gabssnake]

+1 for the awesome power of:

@{prop}: @value;

[suparngp]

+1 for this,
Currently I am doing this to make it happen:

     qwerty: 1 e("; @{type}:") rgb(red(@color), green(@color), blue(@color));

This basically renders an extra property called qwerty which is ignored by the browser.

[fahad19]

👍 would be awesome if this gets merged.

[Soviut]

Yeah, I doubt anybody wants to rush it into an already jam-packed 1.5 release, but if it can be done, that would be fantastic.

[badiezadegan]

a great feature for making right to left pages from left to right ones... 👍

[lukeapage]

later pull request merged.