Add autoprefixer? like "Myth"..

[stevenvachon]

https://github.com/ai/autoprefixer
It's what Myth uses.

Would be cool. Wouldn't need to use mixins for as many things.

[jonschlinkert]

This is something that has been discussed here numerous times, but I think the consensus has been (should be still) that this is not something that belongs in less.js (for all of the reasons described in the other issues - run a search and you'll find a few).

However, I do think this is a great example of the kind of thing plugins ought to do, so I'll leave this open until others have a chance to weigh in on it.

[mdo]

Came here to look up and ask for the same thing. It'd be amazing to see the preprocessors like Less and Sass address this.

[stevenvachon]

If it were written as a plugin, would it affect sourcemap accuracy?

[seven-phases-max]

Hmm, and why you need it to be integrated into Less? You can use it with Less w/o any special integration.
And yes, Autoprefixer supports sourcemap input since v1.

[mdo]

From my perspective, it'd be awesome to see Less and Sass address this to help move projects and the web in general forward. Having to create extensive libraries of mixins just sucks. Folks want a mixin for everything, but I don't think that should be the case. Mixins make the most sense when creating code shortcuts (e.g., clearfix, image replacement, etc).

Moreover, I'd argue the vision of a CSS preprocessor should be to eliminate itself. Improving the core CSS language should the ultimate goal, and having this as part of Less and Sass opens the door to so many more people for writing more bulletproof code, now and forever.

[seven-phases-max]

it'd be awesome to see Less and Sass address this.

Hmm, I'm not sure I understand how (and why) preprocessors should "address this" specifically. We just do put the AP tool after the PP tool in the building chain, that's it.

[mdo]

Right, that fixes it for us, and those using Grunt. Not everyone uses Grunt or another build tool.

When I say Less and Sass should address this, I mean that auto-prefixing CSS3 properties should happen automatically (and be configurable) within the core Less and Sass projects. An external tool shouldn't be necessary.

[stevenvachon]

@seven-phases-max autoprefixer supports source maps with less' output css, not less' raw source input.

There's also the argument for autoprefixer in "development mode", without the need for a task runner.

[jonschlinkert]

I'd argue the vision of a CSS preprocessor should be to eliminate itself.

Amen. I could not have articulated my view any better than this line. Sums it up well.

I mean that auto-prefixing CSS3 properties should happen automatically (and be configurable) within the core Less and Sass projects. An external tool shouldn't be necessary.

This is the kind of feedback that I was looking for when I left the issue open. @mdo / @stevenvachon would it make a material difference if this functionality was supplied by a plugin that for all intents and purposes "felt" like it was native, and not like an external tool (meaning that it wouldn't rely on a third party build chain, Less.js would do all the work)?

[stevenvachon]

@jonschlinkert sure, but would it work with Less.js' dev mode and would it produce accurate source maps relative to the Less code and not its CSS output?

[seven-phases-max]

@stevenvachon by "Less.js' dev mode" do you mean client side usage? See #1835.

[jonschlinkert]

@stevenvachon well, that brings up a good point - I guess (like most things) it will depend on expectations. So maybe the first thing to do is for us to outline these things and get consensus on what the autoprefixer would be expected to do.

Then @lukeapage / @seven-phases-max can decide whether or not a plugin would work, or if it needs to be implemented natively.

[jonschlinkert]

also see: https://github.com/less/less-plugins-core/blob/master/lib/auto-prefix.js

[stevenvachon]

@jonschlinkert my expectations would be pretty simple:

• function like Myth (probably not far off from autoprefixer's default settings)
• support client-side usage (Add post-processor callback for less(pre-processor) generated css in browser mode #1835, perhaps)
• export an accurate source map that is relative to the Less.js stylesheet and not its CSS output

Not sure if anyone has anything to add to that.

As to whether it should be a plugin or a native feature, I'd push for native as it maintains Less.js' ease of use and brings everything closer to achieving @mdo's summary of what a pre-processor should be.

[stevenvachon]

@jonschlinkert that link you posted, does it have a reference of properties/rules that get prefixed? And, does it—should it—have a source for updates (like autoprefixer does with caniuse.com)?

[seven-phases-max]

Well, my point is: of course there's nothing wrong with implementing autoprefixing as a plugin (when we have the plugin subsystem ready). But this is just a tiny bonus to what we already have. And we are able to put the AP after the PP in whatever build environment (not just Grunt).

Sure, there's always people out there that would prefer "just give me one monster tool that can do everything" way... Well, I don't think I need to enumerate all the cons of the "everything-in-one" approach, especially when it comes to a community-driven open-source development. That's pretty old story. So my personal vision: preprocessors are for generating styles, postprocessors are for prefixing (and similar things), just let each tool do its work at its bests.

@stevenvachon

autoprefixer supports source maps with less' output css, not less' raw source input.

According to https://github.com/ai/autoprefixer#source-map, an output sourcemap of the autoprefixer still should point to the original line in the less file. I dunno about client-side usage though, never tried - probably you're right and it does not work as supposed there.

Either way:
Myth intergrates the AP transparently just because it is the autoprefixer (or more strictly speaking both the M and the AP are front-ends for the same Rework engine) with variables and functions.
Less won't be capable of such level of integration anyway unless you're going to rewrite it from scratch using the same approach (i.e. all the functionality on top of the same parsing engine, i.e. either "Less on top of Rework" or "Yet another prefixer on top of Less").

[jonschlinkert]

I just wanted to link to that as a resource for the discussion. Since @lukeapage developed the plugin (and to my knowledge it's not "officially" released), we should probably get feedback from Luke on it

[jonschlinkert]

Sure, there's always people out there that would prefer "just give me one monster tool that can do everything" way.

Yeah, I think anyone who wants life to be a little easier. Who in there right mind would want to use multiple tools to get one job accomplished?

[seven-phases-max]

Who in there right mind would want to use multiple tools to get one job accomplished?

Someone who knows that the benefits of the modular approach are infinite :) (it's a rhetorical question of course, you know that better than me... btw. out of curiosity, how many node-modules you have installed currently?)

Doh! I can't compile my Bootstrap 4 because they still did not updated their "I can do everything" tool for a while as one of its 983 glued modules has some minor bug they have not managed to fix yet.

[stevenvachon]

Doh! I can't compile my Bootstrap 4 because they still did not updated their "I can do everything" tool for a while as one of its 983 glued modules has some minor bug they have not managed to fix yet.

@seven-phases-max we already have that "problem" with clean-css.

[seven-phases-max]

we already have that "problem" with clean-css.

@stevenvachon Yep, and there're some thoughts of getting rid of it too...

[stevenvachon]

@seven-phases-max replaced with custom code, I imagine? If so, what about writing a custom autoprefixer for Less.js ?

[stevenvachon]

@seven-phases-max after reading more into your link, their primary concern is that clean-css is not related to Less.js' use of it, so it's more dangerous. Less.js using autoprefixer would be directly related. However, rework is a big engine that doesn't work on client-side, at least currently.

[mdo]

Regarding the core or plugin question:

Yeah, I mean if it fucks up everything to make it part of the core, let's not do that. But if the intent is to help as many folks as possible, this should ship as part of the core.

[lukeapage]

Hi all,

I completely agree with this being necessary and in fact I already made a
proof of concept in less core plugins.

I want to adjust it to work differently, taking a configuration rather than
putting the emphasis on the coder.

It has not occurred to me that it is a hassle to have it in a different
repo - my vision is you would do an npm install and then add a command line
option and it would just work.. I don't think that's too much to ask? Maybe
when people talk about plugins it sounds scary, but I really hope it to be
a core consideration.

Part of the reason I thought of using a plugin is because I thought it
would have limited appeal - because of auto prefixer and because its a
breaking change to swap to auto prefixing (although I believe that's what
people should do).

Another quicker option is to make a plugin that uses auto prefixer or like
css compression lessc can pull in the autoprefixer repo... I was going to
investigate whether I thought a plugin written by me could offer or do
anything more than what auto prefixer does already and then bring it up.

People complain if lessc brings in too many dependencies that people don't
use so that is another consideration.

Its also been pointed out that tying yourself to another repo like we do
with clean css forces us to up our version if they make breaking changes,
because we may expose those breaking changes.

[lukeapage]

Just actually reading all the comments, I think, lets do this.

1. Implement as a plugin
2. Consider moving completely to core

Because its not a different implementation between the 2.

Also just to be clear, I want to remove cleancss from the node api for
less, it will still be referenced from lessc for now.

[jonschlinkert]

👍

[stevenvachon]

@lukeapage will your solution work on the client side? If not, we might as well use autoprefixer, no?

[lukeapage]

Yes it would work both places and yes you can also already use postProcess
on the browser to run it through auto prefixer.

[matthew-dean]

Agreed with creating as a plugin. Autoprefixing is not a simple task (and most over-prefix), so let's keep the core light. As a core community-supported plugin is fine, but then it's opt-in.

[matthew-dean]

Incidentally, it would be brilliant if an auto-prefixer didn't just add -webkit- and -ms- and -moz- to everything under the sun, but actually used up-to-date data from caniuse.com, and only appended based on:

1. The CSS property I'm using.
2. The minimum version of each browser I'm supporting.

Also, interestingly, in the case of keyframes, an autoprefixer would need to duplicate entire rulesets, not just individual properties. But all that can be part of the auto-prefixer plugin wiki/issue/repo, wherever it lives.

[jonschlinkert]

actually used up-to-date data from caniuse.com

Wouldn't it be even better to use depend on autoprefixer, and let that lib do all the heavy lifting? I'm good with @lukeapage's decision on this since he's much more familiar with the challenges and requirements. But it does seem like we would be recreating a lot of work that has already been done by a library (and some smart folks) dedicated to the task of autoprefixing. So before we finalized anything I just wanted to throw this out there mainly because I think we might get bitten by the nuances and edge cases that we're not thinking about.

[jonschlinkert]

fwiw, @matthew-dean I agree that the things you're mentioning would be pretty awesome. as a rule of thumb though I like to lean towards using established solutions over recreating the wheel (unless the other wheels are broken)

[matthew-dean]

Oh, that link was mentioned but it wasn't mentioned that it was using that methodology. I'm not saying anything different, then. Seems smart to just wrap a less plugin around that lib.

[jonschlinkert]

👍

[lukeapage]

Having looked at autoprefixer it seems silly to reinvent the wheel when ap
does so much and supports sourcemaps.

I will add it to our 2.0 deliverable, which shouldn't be too far away,
depending on how much time I get.

[stevenvachon]

Along with this, why not just include Myth as a possible post-processor option? Excessive?

[seven-phases-max]

@stevenvachon If I understand it correctly the agreement is to provide whatever post-preprocessing via plugins and not as a dedicated core-options. (I.e. to add autoprefixer or myth or anything you just write a plugin which registers itself as a postprocessor and applies desired transformations to the output CSS). In other words it looks like we're building mini-grunt here 🚲 :)

[stevenvachon]

Ah, yeah, I prefer that approach. And, haha, I don't use task runners as much anymore; maybe others are doing the same?

[seven-phases-max]

I don't use task runners as much anymore; maybe others are doing the same?

You will then. lessc/less.js becomes a task-runner as soon as you put all that stuff in. So it's just a matter of naming things by their true names w/o getting shy ;)

[stevenvachon]

What I mean is that I don't use Grunt/Gulp much anymore. Lately, I've just been using npm-scripts and a build.js with each lib's programmatic API.

[seven-phases-max]

What I mean is that I don't use Grunt/Gulp much anymore.

Yes, I've got it above. I mean it does not matter how the thing is named: gulp, grunt, build.js, build.bat, build.sh, lessc (with all stuff inside), in general it's all the same "build chain" essentially.

[stevenvachon]

A plugin architecture may not even be necessary if we have a callback that supports a Promise. Can avoid becoming a mini task runner.

[seven-phases-max]

A callback also may be not necessary since less.render "returns" a CSS string one can do everything with he wants to.

These ("external tool wrapper") plugins are still necessary only because they'll keep asking for a monolith tool no matter what.

[lukeapage]

(maybe you knew but) less.render returns a promise on v2 if no callback is
specified.

[seven-phases-max]

less.render returns a promise on v2 if no callback is specified.

Yes, my bad, I guess just overgeneralized things a bit to not confuse even more :) (In other words, the real purpose of the callback and/or promise there is that it can make async things more simple and/or make error handling more easy... If that would not be necessary it could just really return a string and never care of anything that happens after that (if it could be "just" Less compiler :).)

[lukeapage]

No problem, I was actually replying to Steve!

[stevenvachon]

😄 I hadn't checked much of the source before saying that. Most everything seems to have been thought of, which is awesome.

[lukeapage]

less-plugin-autoprefix is now on npm and works with the (just release) beta v2 of lessc. I've started mentioning autoprefixer in the docs and I hope more people take advantage of how easy it is to use now, even without a build process.