Variable selector "string" improperly parses comma

[scottgit]

This StackOverflow question lead me to test what I thought would work, but failed. Namely, this example:

@inputs: input[type=text], input[type=email], input[type=password], textarea;

@{inputs} {
  &:focus {/*properties*/}
} 

Did not produce what was expected, as it failed to recognize the commas as separators of individual selectors. So instead of this expected output:

input[type=text]:focus,
input[type=email]:focus,
input[type=password]:focus,
textarea:focus {
  /*properties*/
}

It produced this unexpected output of just adding the :focus on the end of the whole variable value:

input[type=text], input[type=email], input[type=password], textarea:focus {
  /*properties*/
}

If the variable interpretation for selectors uses the same algorithm as when a variable is in a string, I can see "why" it is doing it that way, but it would seem to me that, at least for the case of the , in CSS, the variable interpretation needs to recognize it is dealing with a selector at that point, and should then take the next step and parse each of the commas to separate selectors, so that all nested uses of & will attach to all the appropriate selector strings.

[lukeapage]

There are several issues raised all around the fact less does not parse
variable selectors.. part of this is because a user may have escaped the
selector because less couldn't parse it.. however, generally it seems there
is a lot of support to at least try to re-parse once the variable is
evaluated.

[pavlovich]

I would like to see this issue addressed as well. It would be nice to be able to define a set of selectors and refer to them in various places throughout my LESS files via a variable name.

[scottgit]

@pavlovich While I would still like to see the capabilities noted in my original issue, there is a work around to get the functionality of assigning properties to a set of selectors defined in a variable using the capabilities of LESS 1.7. Consider this:

@inputs: {input[type=text], input[type=email], input[type=password], textarea {.getProps()}};
@pseudo: ~':focus';
@props: { /*properties */};

.setProps(@selectors; @props; @extension: ~'') {
  @selectors();
  .getProps() {
     &@{extension} { @props(); }
  }
} 

.setProps(@inputs; @props; @pseudo);

Which outputs:

input[type=text]:focus,
input[type=email]:focus,
input[type=password]:focus,
textarea:focus {
  /*properties */
}

So I can assign a pseudo class if I want or not, and pass a set of properties as needed. The key is to put the mixin .getProps() call into the block that is defining the selectors for variable @inputs, which is then called as a local mixin inside .setProps() so that the properties get put where we want them. The @extension could be any escaped string to add to each selector as an additional part of the selector string. Above I do :focus as a pseudo class, but I could have done ~' > div + div' as a child and sibling combination, or whatever.

[erquhart]

@seven-phases-max so ReadyForImplementation means this is coming, but Low Priority means don't hold your breath. Any idea if this will happen in the near future?

[seven-phases-max]

ReadyForImplementation usually only means it's just decided that it may be in if someone implements it (not necessary coming soon or ever at all if nobody finds time to implement it).