Consider how to handle autoprefixer usage

[alexgibson]

I just noticed today we're using autoprefixer in our Sass compile step. This makes many of our mixins redundant, and is actively overwriting their output, which may cause some confusion or unexpected results.

My immediate reaction was "yay, let's remove a whole bunch of our mixins 🎉 ", but on further thought doing this would have some wider implications that may require some discussion. On sites such as bedrock for example, we're not using auto-prefixer (yet, but we could in future if we needed) but we would want to compile our own Sass. Compiling from source that no longer uses our mixin library would result in no vendor prefixes at all, which is something we probably don't want.

We either need to switch to autoprefixer and make it a recommendation/warning for all sites that compile from source to handle that in their own build step, or we need to carry on using the mixin library.

Thoughts?

[alexgibson]

This also another reason why we should fix #90

[craigcook]

We've also talked about using PostCSS for autoprefixer + mqpacker (#20), which if we compile per component we could do on the Protocol side.

[alexgibson]

We've also talked about using PostCSS for autoprefixer + mqpacker (#20), which if we compile per component we could do on the Protocol side.

Adding in features like this really opens a wider discussion for how we want sites to consume our CSS. The more custom things we add into Protocol, the harder it becomes for other sites to compile from source to get the same result in their own pipelines.

Possible options:

• We start recommending that sites should use the pre-compiled CSS as the default method. The problem with this is that sites can't then specify things like their own media root directories, so I'm not sure how much mileage it may get. Sites may also want to do further custom optimizations.
• We create some sort of build script that sites can run in their own pipeline, which compiles the CSS the way we want it to be consumed. Supporting this may be both complex and time consuming though.
• We only offer optimized pre-processed CSS, and add some docs on extra steps that may want to be taken should a site want to self-compile.
• We don't get so fancy in Protocol itself, and instead offer sites some recommended plugins to further optimize the CSS in their build step.

[craigcook]

Given the options, I would probably land on the side of "keep it simple and let the consumer compile." If they want to use autoprefixer or anything else with PostCSS they obviously can, but we shouldn't require anything beyond vanilla Sass/SCSS.

Which means we could probably keep a few of our prefix mixins but should re-evaluate what properties really still need prefixing. Current use of autoprefixer was a holdover from Drizzle, I'm not even sure it's doing much at the moment (I didn't even know we still had it).