Elm-css vendor prefixes

[hexedhash]

Hello!

I’m curious to learn how folks who use elm-css are adding vendor prefixes to their css.

I saw this [seemingly outdated] github thread but don’t quite understand how something like webpack+postcss could add prefixes to dynamically generated css.

[rtfeldman]

don’t quite understand how something like webpack+postcss could add prefixes to dynamically generated css

At the time, elm-css had a CLI which generated static stylesheet files. A few years ago we changed it to the current runtime generation design, and that’s what it’s been ever since!

[ymtszw]

In our team we do not insert all the vendor prefixes in automatic manner like we do with autoprefixer (rather, we cannot). It is indeed a shortcoming of current style generation procedure of elm-css (= style-components-ish way). BUT, it definitely provides us a convenient and safe way of managing css in Elm so we decided to live with that.

Css shows (in many cases) “can do one thing in several different ways” aspect, so what we currently do is:

• If we can avoid a css feature requiring polyfills/prefixing, stop there and consider using other older, well-supported APIs to achieve the same thing(s)
• If we definitely need some newer css feature with prefixing, just do so “manually”, e.g. using property function like property "-webkit-***" only where we need it.
  • If such requests arise from many places in your app, simply make it an “extra” API in the codebase like Css.Extra.someFeature. We have batch to put multiple lines of css directives at once, so it can be utilized here to employ prefixed directives with single function call.

Empirically, this approach is working well since “opportunities where we absolutely need latest, cutting-edge css feature(s)” are relatively slim, so blanket auto-prefixing is not that must-have in reality.

Of course, YMMV, and your needs must vary from ours. Also this approach definitely requires case-by-case investigation on newer feature usages so takes extra time and effort.