Closed jonathantneal closed 8 years ago
+1 for this!
I've reviewed this as well and agree with the changes.
Awesome, thank you so much for the reviews. Pinging @tlovett1 and @ericmann to maybe get this especially on their radar.
So does this use PostCSS entirely instead of Sass?
Sass is still here, just as before. Nothing about Sass changes. Since Autoprefixer is now a PostCSS plugin, it correctly identifies the Non-Sass Autoprefixer option as the Non-Sass PostCSS. It also adds a secondary grunt task to better compile CSS for old IE using PostCSS, by resolving media queries, converting rems to px, etc.
:+1: since I was doing some of this for another project :smile:
@jonathantneal and everyone, great discussion here!
PostCSS, in conjunction with Autoprefixer, also allows the Front-End Engineers to rely less on Sass mixins that add vendor prefixs. In some cases, if a browser no longer requires the prefix and mixin has not been updated, we end up with additional styles that are no longer needed. Autoprefixer checks against the CanIUse API, and then adds the needed vendor prefixes to the stylesheet. Personally, I feel this requires maintenance in the long run.
@allenmoore To clarify, you feel which approach requires more maintenance in the long run? I think we all agree, but that ending made me unsure.
@tlovett1 +1 from me. Autoprefixer, as currently defined in the generator, is deprecated and throws warnings in the console to let you know. I'm also a fan of what PostCSS brings to the table, in general.
@JonBellah That should read, "I feel this requires less maintenance in the long run." And I am referencing using PostCSS with Autoprefixer.
A major update to how (S)CSS files are handled. This changes the option of Autoprefixer to PostCSS and provides the following improvements:
$oldie
::
to compatible:
pseudo-elements in a selectorThese changes are based on successful practices I’ve seen leveraged by other 10up developers and of which I have been using as well.