4.0 => deprecation + alias to postcss-preset-env ?

[MoOx]

4.0 => deprecation + alias to postcss-preset-env ?

[ai]

I think Autoprefixer should be in it. It is “future CSS to write today” :)

[shrpne]

I think Autoprefixer should be in it.

For me it will be easier to use preset-env and autoprefixer as separate packages.
They have different purposes: Autoprefixer is about prefixes, and preset-env is about polyfills.
Also there are a lot of tools that include Autoprefixer (like cssnext, cssnano, etc.), and when I have to combine them, they do double work.
Also for now there is an issue, that cssnano uses outdated autoprefixer version, and a lot of tools relies on cssnano (like webpack loaders), and when i try to use modern Autoprefixer's features like browserslist not dead, my build fails.
Not including Autoprefixer should prevent all these issues :)

[jonathantneal]

At this point, we are just waiting on a postcss-preset-env website, which is being actively worked on by others. I haven’t had any hours to put toward it, except on weekends. When that is ready, I think we should:

• publish a new major release that aliases postcss-preset-env (perhaps defaulting to stage 0)
• immediately publish an npm deprecation notice

How does this sound?

[kossnocorp]

I think the alias is a great measure.

[ai]

I like the idea.

[jonathantneal]

It’s a big undertaking to update the website. However, the CHANGELOG one would expect if upgrading from postcss-cssnext to postcss-preset-env as if it were the v4 major update would be:

Removed:

• autoprefixer (or should this be included by default, @ai?)
• pixrem (generates pixel fallbacks for rem units)
• postcss-calc (reduces calc, not really a polyfill)
• postcss-color-function (color() is now color-mod())
• postcss-color-rgba-fallback (IE8 fallback for alpha colors)
• postcss-pseudoelements (IE8 fallback for : => :: pseudos)

Added:

• postcss-color-mod-function (color() is now color-mod())
• postcss-dir-pseudo-class (:dir(ltr) and :dir(rtl) directional selectors)
• postcss-focus-visible (requires WICG focus-visible js polyfill)
• postcss-focus-within (requires focus-within js polyfill)
• postcss-logical (new margin-block, inset, etc. directional properties)
• postcss-page-break (fallback break-* properties with page-break-* alias)

Available but inactive by default (Stage 3+ is active by default):

• postcss-color-rgb (Stage 2)
• postcss-custom-media (Stage 2)
• postcss-custom-selectors (Stage 2)
• postcss-nesting (Stage 1)
• postcss-apply (Rejected as a standard)

[MoOx]

One thing I am thinking about: why removing old stuff like pseudoelements or pixrem? This should be disabled by browserslist right? Are you going to keep removing "old" stuff regularly?

[jonathantneal]

@MoOx, that’s a fair question. I set CSS3 as a baseline and removed plugins targeting browsers below that baseline. Things like pseudo-elements impact IE8, but so do media queries, rem, nth-child, etc. It seemed like those kinds of polyfills should be moved into something legacy (like oldie). Plus, there are other transformations one may need to support those browsers, anyway:

postcss-unmq (to selectively remove @media queries)
postcss-unnot (to selectively remove :not selectors)
postcss-unnth (to remap :nth-child selectors)
postcss-unopacity (to write fallbacks for opacity)
postcss-unroot (to write fallbacks for :root)

[jonathantneal]

I would love to build a website, but my first commitment is to stability, so I haven’t had time for marketing material. I will put something up on Twitter

[jonathantneal]

Hey, I’m also fine moving preset-env into cssnext, or making them synonymous. What do you and other admins think? What’s best for the users?

[MoOx]

poke @Semigradsky @RyanZim

[MoOx]

poke @ai

[MoOx]

@jonathantneal what would you prefer?
Do you plan to make a website like cssnext have? Are you interested in doing the same kind of doc if we go for cssnext becoming an alias?
Do you like cssnext name or you prefer preset-env?

[SterlingVix]

@MoOx : I'm integrating postcss-preset-env into our codebase right now after having just upgraded to Babel v7. Assuming postcss-preset-env is intended to work the same as Babel's babel-preset-xxx presets, I like the naming convention postcss-preset-env.

This may be my JS bias (more JS experience than CSS), but I feel like the postcss-preset-env naming convention takes a bit of cognitive load off while I'm trying to figure out how to integrate this tool and what it's intended to do, just because it's already familiar to me. cssnext doesn't mean anything specific to me; postcss-preset-env tells me "this is a bunch of plugins that integrate with the rest of my tooling."

Just my 2¢. 😀

[MoOx]

I will take care of this issue and deprecated postcss-cssnext soon.
I just want to do this with the right amount of time to make this right. I will update the site etc with banners & shit. @jonathantneal did you plan a website or something for this plugin? Or nothing more than the README? (just to know)

[MoOx]

Yep. Will add a banner on cssnext website and redeprecate cssnext package in addition to postcss-cssnext. Will also tweet and write a blog post about it.

[jonathantneal]

The site is up. https://preset-env.cssdb.org/

[MoOx]

Good. Nice! That's great!
I will deprecate cssnext as soon as I have some time available!

[jonathantneal]

What’s our timeline, @MoOx? Would it help if I applied a deprecation notice?

[MoOx]

This week. I am preparing a blog post about it and it will be good. Stay tuned :)

[MoOx]

On it.

[MoOx]

@jonathantneal I think you should add on the homepage of your website the stage configuration. I don't find how to configure this on the website.

[MoOx]

I have added a npm notice and a banner on the website that say

postcss-cssnext has been deprecated in favor or postcss-preset-env. Read more at https://moox.io/blog/deprecating-cssnext/

Tell me if that ok. I will close all issue and warn about this on twitter etc.