Auto Prefix replacement

[lukeapage]

A really popular issue is the ability to have variable properties.. but the main/only use-case I've seen is prefixes.

I saw that stylus supports automatically expanding properties with prefixes..

For cases where the syntax is different we suggest people use a mixin for that property and alter the arguments to work with different versions.

For cases where the syntax is the same, I suggest we have

-*-gradient: blah;

which is transformed to a set of prefixes

-webkit-gradient: blah;
-ms-gradient: blah;
-mozilla-gradient: blah;

which can be overridden with a option

--prefixes=ms,webkit

[jonschlinkert]

In cases where the syntax is the same, where would the prefixes be created/managed? My thinking is that vendor prefixes are technically only on properties that are not uniformly implemented and standardized across browsers, and new properties are proposed all the time. So at any given point, many properties have different levels of support with different browsers. Consider CSS masks, filter effects etc. etc. Some properties would only get one or two prefixes, and others might get five, is there a way (or desire) to manage that?

[lukeapage]

if you want to manage that, I think it should not be less' job but you should write a mixin for each property.

For complex properties like gradient I would not recommend this feature - it is more for simple properties where the syntax is unlikely to change and therefore a browser implementing a previously un-implemented prefixed property is highly unlikely to hurt (and will instead mean the website is just ready). I think a way of deciding what browsers should be switched on for what properties is not desired (and I think that if it is, this feature should probably be abandoned).

This ties into the big complaints a while back that people kept only using webkit prefixes and mozilla started recognising some webkit prefixes.

[SomMeri]

Just an idea: what about putting prefixes into variable and then use interpolation like syntax?

@prefixes: ms, webkit;
-@{prefixes}*-gradient: blah;

could compile to

-ms-gradient: blah;
-webkit-gradient: blah;

It would be flexible and does not require entirely new syntax.

[SomMeri]

Browsers ignore a declaration with an unknown property. As long as that is valid, I have a workaround. It is possible to create mixin that adds vendor prefixes to declarations.

The idea is to combine

• invalid property declaration,
• escaping,
• and string interpolation.

We can use interpolated escaped value to close invalid property with semicolon and append vendor prefixed declaration to it: hack: 1 ~"; -moz-@{declaration}";

Sample input:

 /* The mixin adds vendor prefixes into property declaration. Supported 
     prefixes: -moz-, -webkit-

 Parameters:
   * @declaration: string with property declaration
 */
 .vendorPrefixes(@declaration) {
   // vendor prefix: mozilla
   hack: 1 ~"; -moz-@{declaration}";

   // vendor prefix: webkit
   hack: 1 ~"; -webkit-@{declaration}";

   // vendor prefix: ...
 }

 #usePlace {
   // pass the declaration about to be vendor as a string parameter
   .vendorPrefixes("gradient: blah");
 }

Less.js-1.3.3 output:

#usePlace {
  hack: 1 ; -moz-gradient: blah;
  hack: 1 ; -webkit-gradient: blah;
}

Browsers should ignore hack: 1 ; part.

[lukeapage]

@SomMeri that is a work-around but ideally we would like to develop less so that you don't need to hack around it.

I still think the simplest is just *

-*-gradient: blah;

and we auto replace * with a configurable list of properties.. no interpolation of property names, no hack, no hassle...

We could even keep the less language the same and just add an option that if on, and you use any prefix, it auto adds in the other ones...

[jonschlinkert]

👍

[SomMeri]

@lukeapage I was mostly sort of proud about finding that trick and wanted to brag. I'm definitely not saying that you should not implement the feature, just that there is usable workaround in the meantime if someone really want.

The option to add all prefixes everywhere there is at least one prefix might do too much through. People might need all prefixes on some places and only some of them on other places. And if a portion of an old style sheet already have them listed all, they may not want to multiply them into all times all.

[matthew-dean]

The problem with -*-gradient: blah; is that you don't necessarily always want to use the same prefixes. Browsers unprefix certain CSS properties at different times.

I've been evaluating a lot of LESS mixing libraries lately, and their implementation has taught me a lot about what's missing in the LESS language. This came up because I see a ton of CSS3 mixins (in almost every library) that have huge blocks of repeating property declarations.

But, as I said, it's not always the SAME prefixes. I was actually going to come here and propose something almost identical to what @SomMeri had (referring to this):

@prefixes: ms, webkit;
-@{prefixes}*-gradient: blah;

The asterisk is an interesting way to do it. But yeah, same idea: I was thinking you could define your list of prefixes once (either globally or per block or both), and use that to make a single property declaration.

Fortunately, I think the web is evolving to where prefixes will eventually (mostly) be a thing of the past, but right now, they're still an unfortunate reality, and one of the biggest reasons people use a LESS mixin library to begin with.

[matthew-dean]

Even better, let's go one step further!

{-ms-, -webkit-}*gradient: blah;   // Is it more semantically correct for dashes to be within the braces?
// Is the asterisk needed, or does this make sense:
{-ms-, -webkit-}gradient: blah;

By that, I mean, make an alternate allowable syntax that allows you to inline the prefixes. Would make it really easy to read, with the assumption that it will convert the above to:

-ms-gradient: blah;
-webkit-gradient: blah;
gradient: blah;

Unless somehow it needs to be more explicit to include the non-prefixed value, but not sure how you would define that, since it's essentially "nothing". Nor can I think of cases where you would use prefixed values only.... but I may not be thinking of cases.

Also, you'd want to support:

    background-image: {-moz-, -webkit-, -o-}*radial-gradient(center, @color1 0%, @color2 100%);  // AND/OR
    background-image: @{prefixes}*radial-gradient(center, @color1 0%, @color2 100%); 

So, the parser would read this syntax as: "Create a copy of this declaration substituting each member of the list, and finally a copy without any members of the list.

[matthew-dean]

Ooo!

And THEN I could do:

h1 {
  border{-top, -bottom}*: 4px solid #9a603d;
}

I love this new syntax that doesn't exist yet! lol... Thanks, @SomMeri! ^_^

[jonschlinkert]

Okay, before eveyone hates me hear me out lol... I really don't see a need for this at all for vendor prefixes alone. Not even a little bit. To reiterate what I said early on: #1199 (comment), given that prefixes are different for many properties, how would this really end up educing any work for developers? Presumably, this would only be valuable when you're not using a mixin, right? Because when you are using mixins, you don't need this. You've already created a mixin once (one time, that's all... no need for reducing labor there), where any time saved in not having to write out each property is lost again in having to create "mixin-specific-vendor-specific-property-variables", which won't even work for things like background gradients because the vendors don't even use the same syntax. Why not just use a nice clean mixin which is "pre-loaded" one time with the properties you require?

Now that I got that out... to @lukeapage's point in the original comment:

the main/only use-case I've seen is prefixes.

Aha! I think I have a much better use case for this, and it goes something like this: "CSS Custom Properties for Cascading Variables Module Level 1".

Love it or hate it (and I personally hate it) this is happening, so custom (variable) properties is probably one of the most important features Less can implement to prepare for this. For example (from the CSS spec):

:root {
  main-color: #06c;
  accent-color: #006;
}
/* The rest of the CSS file */
#foo h1 {
  color: var(main-color);
}

How does Less.js respond to this? I'm not entirely sure, but what I'm thinking is that we might want to approach this differently than what we're thinking so far on this Issue, and we should consider the syntax both for creating custom properties in Less.js, as well as how Less.js might generate custom properties from Less variables to help users prepare for "CSS Custom Properties for Cascading Variables Module Level 1". I guess I see this discussion as addressing only one side of what has become a two-sided coin.

So maybe we need a feature or additional option that converts this:

@main-color: #06c;

into this:

:root {
  main-color: #06c;
}

I'll think about this more but I wanted to at least throw this out to see what kinds of ideas come back.