Vendor prefixes in nested Less selector

Question

I am trying to use Less as efficient as possible. Now I want to replace the color of a placeholder, which I normally in CSS would do like this:

input::-webkit-input-placeholder /* WebKit, Blink, Edge */
{
    color: #000000;
}

input:-moz-placeholder /* Mozilla Firefox 4 to 18 */
{
    color: #000000;
}

input::-moz-placeholder /* Mozilla Firefox 19+ */
{
    color: #000000;
}

input:-ms-input-placeholder /* Internet Explorer 10-11 */
{
    color: #000000;
}

Now I thought using nested selectors in Less I could use:

input{

&::-webkit-input-placeholder, /* WebKit, Blink, Edge */
&:-moz-placeholder, /* Mozilla Firefox 4 to 18 */
&::-moz-placeholder, /* Mozilla Firefox 19+ */
&:-ms-input-placeholder /* Internet Explorer 10-11 */
 {
     color: #000000;
 }
}

Unfortunately that does not work like I expected. When I only use one selector (without the comma's) it works fine, but that means I would still have to make four nested selectors for each prefix, which is not efficient. How can I accomplish the effect of the first CSS block in Less with the less possible lines?

Note: the full code block is more extensive, with more nested rules. Of course for this example I could just comma all the selectors with just CSS - but I want it to work in a nested Less-selector.

I think these vendor-prefixes can be added automatically if you use some sort of pre-processor for your less code. If not this is a pretty interesting question. +1 — X.Creates, Apr 08 '16 at 00:53
I just checked the autoprefixer does not add these prefixes automatically. I just tried your LESS code; it seems to produce the right output which is what you expected. — X.Creates, Apr 08 '16 at 00:59
@LiXinyang Thank you for your response. I digged further into it, and it indeed seems to produce the desired output. Only the browsers will not parse the right color untill the selectors are defined seperately. so the problem seems to be in the browser, not in incorrect LESS syntax. — BasC, Apr 08 '16 at 02:35
I also looked into the preprocessors; there are a few solutions and good processors, but they do not seem to support all properties (like the placeholders). I could create a shortcut of course using property name interpolation, but with the diferences in property's (`input-placeholder` vs `placeholder`) that would make it more complex than just declaring it four times. — BasC, Apr 08 '16 at 02:37

score 3 · Accepted Answer · edited May 23 '17 at 11:45

Disclaimer: As always I don't recommend using Less mixins for vendor prefixing stuff. They are best left to libraries like prefix-free or Auto-prefixer. This answer is just to show how similar things can be handled using Less.

Like you've already found out (and mentioned in comments), grouping of vendor prefixed selectors will not work because the User Agent will drop the entire rule when it comes across a selector that it does not understand. You can read more about it in this answer.

This is not a problem with the Less compiler. It will compile and output the code as expected.

One way to avoid writing the four selector blocks again and again would be to put the vendor prefixed selectors into a mixin which accepts a ruleset as argument and then call it wherever required. Below is a sample code for your reference.

.placeholder(@rules){ /* no need to repeat, just copy paste this once in your code */
  &::-webkit-input-placeholder /* WebKit, Blink, Edge */
  {
    @rules();
  }
  &:-moz-placeholder /* Mozilla Firefox 4 to 18 */
  {
    @rules();
  }
  &::-moz-placeholder /* Mozilla Firefox 19+ */
  {
    @rules();
  }
  &:-ms-input-placeholder /* Internet Explorer 10-11 */
  {
    @rules();
  }  
}

/* call it wherever required */
input{
  .placeholder({
                color: red;
                })
}
input.somethingelse{
  .placeholder({
                color: black; 
                padding: 4px;
                })
}

Yes, it was me. Just to describe my position. While I don't usually downvote the prefixing Q/As (since it's not the purpose of the SO to learn how to use one's time efficiently). But in this particular case it's just ridiculous, while it's totally valuable for the op to learn something new of Less by writing his yet another vendor-prefixing-mixin library, every such answer needs to start with "stop wasting your time on prefixing" in big red. Yet again, just to save his, yours, mine and everybody time (future readers must be informed that this *is not* the way to achieve the task at all). — seven-phases-max, Apr 08 '16 at 12:46

Vendor prefixes in nested Less selector

1 Answers1