Emotion: RFC: Builtin prefixer

[Andarist]

As we come closer and closer to releasing v11 this is a good moment to reevaluate what should be included in our builtin prefixer (which doesn't require opt-in).

What browsers should we support? Should we support IE11? Should we setup a market share (%) criteria? What it should be?

Keep in mind that even if we change defaults it will be possible and easy to swap out the prefixer for your own or for the one provided by Stylis (the CSS parser we use) which covers everything that is currently covered in v10.

cc @probablyup @jxnblk @siddharthkp @ChristopherBiscardi @JakeGinnivan @tkh44 @ndelangen @geddski

[probablyup]

I'm all about principle of least surprise, so IMO as long as IE11 is supported by React it's better to just ship support for it.

[adamwathan]

Any reason to not prefix contextually based on browserslist config?

[madou]

Any reason to not prefix contextually based on browserslist config?

I think this is the answer for me tbh - have a default one targeting the large majority but then allowing consumers to customize it. I have that planned for Compiled to be able to pick up the file automatically and then apply it.

would all the config still be done through cache provider?

[probablyup]

Only a certain amount of prefixing can be done at compile time. Pulling in the browserslist dict to do runtime checking for a narrow subset of browsers would be worse than just keeping the existing solution...

[Andarist]

Basically what @probablyup said - we operate at runtime and we can't afford to check browser compat tables. We think it's still best to include some autoprefixing by default to make things just work and also provide seamless upgrade experience for the majority of users. It's just a question about the lowest common denominator we should think of.

[adamwathan]

Only a certain amount of prefixing can be done at compile time. Pulling in the browserslist dict to do runtime checking for a narrow subset of browsers would be worse than just keeping the existing solution...

That's a great reason! 👍 Carry on 😅

[leonardoelias]

Something like the lib. immer did, be interesting, did we get it with emotion?

https://immerjs.github.io/immer/docs/installation

// In your application's entrypoint
import {enableMapSet} from "immer"

enableMapSet()

[Andarist]

@leonardoelias I've seen this pattern - not yet sure how do I feel about it though 😅 It also requires the runtime to check against enabled "features". Parsing is really a hot path and I would like to avoid any work that don't have to be included there.

[leonardoelias]

I understand your point.

I would like to maintain support for IE11 in my applications, but I don't know the cost that this may have.

The react-router version v6 team no longer supports it.
They had excellent gains.

https://reacttraining.com/blog/react-router-v6-pre/#smaller-bundles

[ndelangen]

Storybook will support IE11 for the foreseeable future, We'd have to stay at v10 if v11 had no IE11 support.

[mitchellhamilton]

FYI folks - @Andarist and I have decided that this isn't something we should change for v11 in an effort to get it out soon. (though we still think we should improve this though the default should probably be IE11 + recent versions of evergreen browsers)