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)?