You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In my Feeling Sassy Again article, I mentioned how I thought that Sass was best for proprietary/compiled features while PostCSS was best at browser compatibility and automated/robot stuff.
I think in my ideal world, the CSS stack for this would be something like this...
PostCSS is configured to run Preset Env and Autoprefixer, both of which will change their behavior based on browserslist.
Files ending in .css are processed by just PostCSS.
Files ending in .scss are processed by Sass, then by PostCSS.
This will give us:
The ability to automatically polyfill CSS features based on a project's target browsers.
The ability to opt in to proprietary Sass stuff when we want to, ignore it if/when we don't need it.
That said, the latter point isn't super important to me. If supporting Sass-less compilation means that importing gets confusing, then that may not be a reasonable trade-off.
The text was updated successfully, but these errors were encountered:
In my Feeling Sassy Again article, I mentioned how I thought that Sass was best for proprietary/compiled features while PostCSS was best at browser compatibility and automated/robot stuff.
I think in my ideal world, the CSS stack for this would be something like this...
browserslist
file.browserslist
..css
are processed by just PostCSS..scss
are processed by Sass, then by PostCSS.This will give us:
That said, the latter point isn't super important to me. If supporting Sass-less compilation means that importing gets confusing, then that may not be a reasonable trade-off.
The text was updated successfully, but these errors were encountered: