Browserslist not working?

[joeworkman]

I have configured browserslist to just contain last 2 versions and for some reason all of the webkit prefixes are still getting added. I search several individual properties on caniuse and, from I can see, all webkit browsers do not require the prefixed property. I tried to figure out how to output what it thinks last 2 versions is but could not figure it out.

To Reproduce Steps to reproduce the behavior:

1. Edit browserslist to just contain last 2 versions
2. Run the build and you will see that all webkit prefixes are still there

Expected behavior A clear and concise description of what you expected to happen.

I would expect the webkit prefixes to be removed.

[warengonzaga]

Thanks for reporting this issue @joeworkman I'll check this out.

[eltonmesquita]

As we provide the library compiled with some prefixes I think that any bundler will just keep those and not remove them. If you want to have your own compiled version, you'll have to import things directly from the src folder, which might work but we still didn't test it yet to confirm.

It will probably work just fine in the next major version. You can follow the work and discussion about it on #1331.

[joeworkman]

I have to admit that I am not familiar enough with postcss to figure that out. I could build it with Sass but then you lose the prefixes for all of the classes. This seems like a very reasonable thing to do and probably not difficult of an option to add if you are familiar with postcss (but I could be wrong).

[eltonmesquita]

To be fair, the whole library with all the animations, including all the prefixes, is very lightweight (less than 6kb gzipped). We already ship the library with a minimal amount of prefixes just to guarantee wide compatibility.

Removing the prefixes will probably shave off around 0.5kb or less (gzip is pretty good with repetition, which is the case). Shipping the prefixes won't hurt your audience too, so I don't see a reason to worry about it.

[joeworkman]

It's not all about download time. The browser does have to parse as well. Yes, it's small. But every little bit counts. Especially since prefixes really are just wasted space at this point.

Anyways, thanks for keeping the library going. It's a good one.

[eltonmesquita]

Just to clarify and for posterity, parsing properties with or without prefixes is the same for browsers. Having prefixes shouldn't slow down any webpage at all as the browser will only apply one of the declared version of any css property for any element, that's why we are very careful with the order we declare them (autoprefixer is, actually). Even very underpowered devices won't struggle to parse any CSS. I made lots of experiments a few years ago and even an old entry-level 2.2 Android device with 256MB of ram and a very slow processor for the time (I think it was clocked around 800Mhz) had no problem handling any CSS you'd throw at it, beyond the several bugs that Android browser had.

Besides that, prefixes probably have less impact than some complex selector (*, *::before, *::after { }) and CSS functions (calc()). But even so, no one should stop using these selectors and function as browsers can handle them just fine and performance issues will be very, very rare and will only happen in extreme cases where optimizing other things will probably yield more gains (DOM size, javascript payloads, images and so on).