Do we need autoprefixer?

[nottrobin]

@hatched asked the question - do we still need autoprefixer?

All the major browser vendors have made statements about reducing reliance on vendor prefixes:

Vendor Prefixes Are Fading

Luckily, it appears vendor prefixes are fading away as browser teams look for better solutions. The Chrome/Blink team have adjusted their approach:

“Going forward, instead of enabling a feature by default with a vendor prefix, we will instead keep the (unprefixed) feature behind the “enable experimental web platform features” flag in about:flags until the feature is ready to be enabled by default.” – The Chrome/Blink team

The Firefox team are also on their way to a similar approach:

“For what it’s worth, the current trend inside Mozilla is […] avoiding vendor prefixes by either turning things off before shipping or shipping them unprefixed if they’re stable enough. At least as a general policy; specific cases might merit exceptions.” – Boris from Mozilla

Microsoft Edge aims to remove support for prefixes altogether:

“Microsoft is also getting rid [of] vendor prefixes for Edge. This means that in order for developers to take advantage of special HTML5 or CSS features, they won’t have to use a specific Edge prefix. Instead, they can just code to web standards.” – Mashable

And in practice, the number of prefixes for standard features is fading fast. There don't appear to be any -moz-prefixed pre-standard properties any more, and there are only a small number of -webkit ones.

Although e.g. http://shouldiprefix.com/ still claims you need prefixes for important properties, caniuse.com disagrees - e.g. animation, background-clip, filter, display: flex, display: grid, transform.

Of the browsers we care about, here's a list of basically all of the things vendor prefixes still help with, at the time of writing:

• appearance in Webkit browsers and Edge
• maskin Webkit browsers and Edge
• filter in Edge
• object-fit in Edge
• grid in IE11
• flex in IE11

This list is very short. And appearance, although technically now a standard, is basically purely proprietary, so we probably wouldn't want autoprefixing for it anyway.

mask may well be useful. But do we currently use it?

I'd argue that filter and object-fit support in Edge are hardly centrally important features (Edge comprises 3.86% of our traffic in the most recent analytics).

If we want to support IE11 properly then display: flex and maybe display: grid may be important, but if it's literally just these two properties that need vendor prefixes, running an autoprefixer in every project seems overkill. We could probably just explicitly declare prefixes in just these 2 cases. We could apply the same logic to the mask property, if we use it.

What do people think?

[barrymcgee]

I'm not sure if this has been clarified or not in this discussion or everyone already knows this but I think it's important to point out that Autoprefixer updates itself to do less as browsers adopt standards - that is to say, while it might now be adding 20 prefixes to a certain project at build, next week, it might only add 10 until it will eventually add nothing. At this stage, I'd recommend removing the dep.

Until then, it would seem to me to be a regressive step to remove a tool which currently takes care of prefixing automatically and intelligently and replace it with a responsibility on a developer to keep oversight of browser adoption.

[squidsoup]

Using postcss/autoprefixer doesn't really have much overhead, cognitive or otherwise. Seems reasonable to keep using it until it deprecates itself entirely as @barrymcgee suggests.

[hatched]

I originally brought this up because I saw someone in the channel having issues with it running/compiling or otherwise. I imagine that this took them out of being productive for some time as well as another developer to assist.

So the question was really based around our updated supported browser matrix and that if we no longer require the features of the tool but paying to maintain it then it's a net productivity loss. As with any dependency the benefit needs to be weighed against the costs, not only when things are working as they should, but also when they aren't.

I don't know enough about the various projects currently using it to say whether keeping it is valuable or not. I'd imagine an analysis of the outputs to see what is actually being compiled in would be required on a project/project basis.

[nottrobin]

I think that in that particular case, @pmahnke's autoprefixer issue was a red herring - it was just that autoprefixer, starting with "a", was the first package to fail to download when the network connection wasn't working. If it wasn't autoprefixer, it would have been the next package.

I don't think the maintenance overhead for this package has ever been terribly high (or ever caused any issues at all that I'm aware of).

However, having one more tool in our chain of build steps will always carry a cognitive cost in understanding all the steps between our source files and our production builds. We definitely shouldn't have steps in there that are completely unnecessary.

There is one other subtle cost to autoprefixer - that we are farming off a certain level of decisions to this third party library, and so losing an opportunity for control over our code that might be important. When a feature is prefixed, it is because there is a (usually subtle) difference between that browser's implementation of that feature and the standard. Autoprefixer currently makes the decision about whether we need to care about those differences for us, in a generic way, and usually that's absolutely fine. When we're talking about 10 or 20 such features, I think that was definitely a convenience we wanted, worth the trade-off of losing visibility over those decisions. But when we're talking about just 1 or 2 prefixed features, I think we might want to take back control, make our codebase great again, and start making those decisions on a case-by-case basis again. Especially if we have fair confidence that even those prefixes will have disappeared in the near future.

But I am completely open to the suggestion that this move is currently still premature. I just thought it was interesting that prefixes are now much less important than I realised. It looks like in 6 months there won't be any at all (apart from probably IE11, which will hang around for a while).

I'll bring it up in dev catch-up, but maybe we can all just agree it's premature pretty quickly in which case I'll close this issue for now.

[bartaz]

I think I've spent more time reading this thread and thinking about autoprefixer now then doing anything autoprefixer related in my 3 years in Canonical. This is probably the least problematic tool we have in our chain.

I believe at this point of time it will take us much more effort to make a decision to get rid or it and implement our custom solution for prefixes needed (IE11) then it will save us in potential maintenance or support needed.