Consider removing IE and legacy edge prefixing code

[lukewarlow]

Just an idea but removing code that handles these dead browsers could result in a smaller project size helping to keep people's node modules folders as small as possible. The market share of these browsers is now small enough that many don't need to support them.

Legacy browser prefixing could be maintained in a separate project for those that need it?

Thoughts?

[ai]

I am thinking about it too. The main problem is that removing properties from ./data/prefixes.js will block removing these prefixes from CSS. We can remove hacks, but we need them to calculate prefixed properties.

But we definitely can remove some parts:

1. Remove very hacks of converting values for prefixed properties.
2. Remove flexbox hacks
3. Remove grid hacks

Unfortunately, we still have users of point 3. But I think we can remove it in the next major release (in a year, for instance).

Can I ask you to make a rough count of how it will reduce Autoprefixer size in node_modules?

[Dan503]

Hacks for IE 10 and below can probably be removed but IE11 still has a lot of usage in government and enterprise environments.

I don't think it is worth removing IE11 related hacks until it is dead in even corporate and government environments.

[romainmenke]

helping to keep people's node modules folders as small as possible

Autoprofixer is ±200kb in a random node_modules folder here.
This is already tiny compared to other widely used projects.

I personally prefer keeping any tool that can help support any older browser over a slightly smaller package.

If there is another need to remove those I might get that, but package size seems like a bad motivation in my opinion.

Also please consider financial inequality.
It is not only people in government and enterprise that depend on older browsers.
Persons without the financial means to buy a new device might find services unusable because of a change like this.

This also affects a11y as software and devices for a11y can be very expensive.

The market share of these browsers is now small enough that many don't need to support them.

The market share of older browsers was always smaller and autoprefixer always operated in space of diminishing returns.

Is there any agreed upon threshold were a browser would be dropped?
Having real numbers would help here. In my opinion this should be in the order of 0.01% (99.99% of visits don't use this browser) or less.

[lukewarlow]

With regards to needing to buy new devices that's not really a valid argument because a more up-to-date (not to mention secure) alternative browser is available on all platforms running IE11. I'll admit to not being the most knowledgeable on accessibility tools but afaik Microsoft Edge should provide everything IE11 users need to migrate and again is available on those old platforms.

Microsoft has already made a way to force redirect sites to Microsoft Edge from IE11, which again afaik affects accessibility tools users aswell. It's clear Edge is the new home for these people to move to.

With regards to visitor numbers plenty of sites have 0 IE users, and currently the industry as a whole makes these people suffer with the added size of both dev environment and front end bundles for the "feature" of IE support. Which frankly I don't think is healthy for the eco system.

Does autoprefixer support plugins where IE hacks could be added in externally? And maintained by those who care about supporting this browser?

[romainmenke]

Shipping larger bundles to modern browsers is not the same issue as package size in node_modules.

The benefits of reducing package size in node_modules just do not weigh up to the real effects on end users. Especially on those (elderly, non-western income standards, a11y, ...) who already lack agency here (github).

If you want to reduce your bundle size you can do this by setting the browserslist to whatever you want ;)

[lukewarlow]

Once a browser is no longer supported by the maker, the people who still use it are put at massive risk. Supporting these browsers still on day to day sites just makes this risk larger because they've got less reason to switch or ask others to help them switch. As of June next year Microsoft will no longer support IE. I'm not suggesting this be done as an immediate thing I know it would take time, I just decided to start the conversation now cause I know there would be push back.

There's already issues found with the IE prefixing done in this project from a quick glance at the issues list. How long do you suppose they should be fixed for until the last people on the then unsupported browser are finally unsupported?
That's a genuine question, because at a certain point people don't move on until they're forced to by stuff not working.

Also complete conjecture but 0.01% is probably smaller than the number of bots who pretend they're IE for various reasons.

[romainmenke]

There's already issues found with the IE prefixing done in this project from a quick glance at the issues list. How long do you suppose they should be fixed for until the last people on the then unsupported browser are finally unsupported?
That's a genuine question, because at a certain point people don't move on until they're forced to by stuff not working.

Deciding to actively remove support is different from not adding support in a brand new tool. Being an active part in forced obsolescence is maybe not the right direction?

I am all for upgrading and hope these older browsers really disappear soon.
But I also want to be realistic and acknowledge that not everyone on an old device/browser is using it by choice.

Also complete conjecture but 0.01% is probably smaller than the number of bots who pretend they're IE for various reasons.

That is exactly the reason why a decided on threshold is important.
There is too much conjecture when making choices like this. Browser age, or vendor support status are irrelevant metrics for end users stuck on these browsers.

This should be measured, not only to limit the impact but also to remove opinions (including my own) from the equation.