Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Auto adding vendor prefixes #225

Closed
gossi opened this issue Mar 26, 2011 · 8 comments
Closed

Auto adding vendor prefixes #225

gossi opened this issue Mar 26, 2011 · 8 comments

Comments

@gossi
Copy link

gossi commented Mar 26, 2011

For now, I need to write a mixin for sth like border-radius, gradients, etc. and add all vendor prefixes within the mixin. Could less itself care about this?

.myclass {
    border-radius: 4px;
}

gets transformed into:

.myclass {
    -border-radius: 4px;
    -moz-border-radius: 4px;
    -webkit-border-radius: 4px;
    -o-border-radius: 4px;
}

So mixins for all the new properties coming along are handled internally and we can write cleaner, vanilla css without abusing mixins for that stuff.

@cbesot
Copy link

cbesot commented Apr 4, 2011

Great functionnality indeed.
Something like cssprefixer would be greatly appreciated!

@gossi
Copy link
Author

gossi commented Apr 8, 2011

Another example (I'm currently on), instead of this:

.linear-gradient (@colors, @direction: top) {
    background-image: -moz-linear-gradient(@direction, @colors);
    background-image: -webkit-linear-gradient(@direction, @colors);
    background-image: -o-linear-gradient(@direction, @colors);
    background-image: linear-gradient(@direction, @colors);
}

div.special {
    .linear-gradient(e("#000, ..... , #FFF"));
}

write this:

div.special {
    background-image: linear-gradient(#000, ..... ,  #FFF);
}

@cwallen
Copy link

cwallen commented Apr 11, 2011

I kinda feel like if it can be done through mixins, it probably shouldn't be built in to the core. I did however come across this http://snipplr.com/view/47181/less-classes/ which should help to keep from rewriting them all.

@cbesot
Copy link

cbesot commented Apr 11, 2011

I don't agree with this technique. It significantly increase size of the less css, which is not the goal.
For example, if I want a gradient with various colors at different %, it doesn't work (I can't do mixin for each type of gradient !)

@cbesot
Copy link

cbesot commented Apr 21, 2011

Moreover, ms-filter use #aarrggbb instead of rgba() for colors and mixin can do the conversion.

@gossi
Copy link
Author

gossi commented Apr 23, 2011

I do understand, sometimes it is not welcomed to have an auto prefixing or in some circumstances only a specific set of properties is allowed be prefixed. Thus I propose a directive to make this happen. Some other technologies already such an approach. So lets have a look at them.

  1. use-directive in JavaScript
    "use strict";
    one-line statement to switch to another mode in js. Something similar could be used in less to prefix, "use cssprefix" (Syntax to be improved to less flavor) although this doesn't allow a configuration of which properties are allowed to be prefixed.

  2. mod_rewrite
    The Apache rewrite engine:

RewriteEngine On
RewriteRule <from> <to>

Something similar to this one would first allow the css prefixing and later one can define the allowed prefixes. Sounds good and offers great flexibility. For example there would be different rewrite rules for opacity. The "rewrite rules" need to be defined at the very top of your less styles. Each property that matches one rewrite rule would then automatically translated. Sounds good to me, but on the downside this can grow very large.

  1. Something similar to css-transitions (My Favorite)
    This is what we got here:
    transition: property|all, time, function;
    Leave out time and function and this is what could work for this one here. Once the keyword (lets call it autoprefix) is present, this turns auto prefixing on. The followed parameters specify the allowed properties and we end up with this one:
    @autoprefix: linear-gradient, radial-gradient, text-shadow,... | all; (all needs to be defined)
    Although this lacks flexibility for properties like opacity.

Summary:
Option 1 runs out I guess. Option 2 is good but can grow very large and option 3 is lacking flexibility. So probably the best is an option of 2 and 3:

  1. Define properties for 'all' (less)
  2. Define rewrite rules for those all properties, stick to the standard here (less)
  3. Build the parser to map everything on @autoprefix: *; to the internally build rewrite rules (less)
  4. Offer the posibility to add own rewrite rules (user)

Hey this already can be done with mixins one might say!
Halfways. Some portions truely can. For properties that take multiple and undefined numbers of parameters this isn't possible (e.g. gradients). And we all end up writing css with mixins:
.opacity(0.9);
Instead of writing future-proven, vanilla css:
opacity: 0.9;

@sergej-brazdeikis
Copy link

you can autoadd prefixes using this: http://sjevsejev.blogspot.com/2012/07/lessjs-function-generates-prefixes-for.html

and to write only this:

.pf('transition','all 1s ease-in-out');
.pf('border-radius',3px);
.pf('box-shadow','2px 2px 5px 0 rgba(0,0,0,.6)');
.pf('flex', 1);

@lukeapage
Copy link
Member

move discussion to #1199

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants