postcss-preset-env VS autoprefixer

Switching from a ready-made tool like Sass or a recommendation package like cssnext (deprecated since 2019) or PostCSS Preset Env (archived in 2022), to the modular PostCSS Preset Env plugin set we can choose a helpful and convenient set of future CSS features beyond the current stable client CSS.

To enable the future CSS there is also a plugin called PostCSS Preset Env. This plugin will take the unreleased CSS selectors and change it to the present usable CSS. More info at PostCSS Preset Env

Third, we enable the postcss-preset-env plugin, which adds support for many other cool things

My PostCSS Config contains postcss-preset-env already which should support for CSS nesting. I also installed postcss-nested & postcss-css-variables, just in case.

To solve this I used postcss-preset-env, which allowed me to define a "custom-media" with the name --viewport-lg and the value (min-width: 1024px). As postcss-preset-env also supported nested CSS this allowed for some pretty readable CSS.

If you use PostCSS, postcss-preset-env[1] is pretty neat for reading up on the latest features. E.g. here is the place properties feature[2].

1: https://preset-env.cssdb.org/

postcss-preset-env - it lets you use some cutting-edge CSS but understandable by modern browsers.

https://stylelint.io https://github.com/csstools/postcss-preset-env

Do you use Autoprefixer? https://github.com/postcss/autoprefixer

Simple, fast, and a little bit opinionated, Eleventy Plus Vite features Eleventy 2.0.0-canary, the new Eleventy 2.0 Dev Server with live reload, Vite 3.0 as Middleware in Eleventy Dev Server (using eleventy-plugin-vite), build output post-processing by Vite (with Rollup), CSS/Sass post-processing with PostCSS including Autoprefixer and cssnano, a custom CSS/Sass structure, basic fluid typography based on Utopia, dark mode support, an RSS feed, XML sitemap, and — to top it off — perfect scores on Lighthouse.

w/ postcss-preset-env(v7.8.3): convert modern CSS into something most browsers can understand, determining the polyfills you need based on your targeted browsers or runtime environments. It takes the support data that comes from MDN and Can I Use and determine from a browserlist whether those transformations are needed. It also packs Autoprefixer within and shares the list with it, so prefixes are only applied when you're going to need them given your browser support list.

As others have said, you need to normalize. Also, you may need something like autoprefixer if you're using styles that have different vendor prefixes. https://github.com/postcss/autoprefixer

Mmm maybe it's not gap then, maybe it's some other property. Maybe autoprefixer could help. Or polyfills, as other user suggested.

Of course, we have great tooling for that: Autoprefixer, PostCSS and Stylelint for CSS transformation, Babel and Webpack for JavaScript transpilation and bundling, ESLint for code analysis, and many others.

Bulma uses autoprefixer to make (most) Flexbox…