Adopt a "do not cause harm" policy for "future css" plugins

[romainmenke]

The more time I spend here and try to align plugins with their respective specifications the more I notice the harm we can and do cause by moving to fast.

I really want to avoid that we continue to poison the well on proposed features.

Adopting a solid policy and guidelines might help.

see : https://github.com/w3c/csswg-drafts/issues/7150

[romainmenke]

Some aspects and thoughts :

• moving fast and making "future css" available to stylesheet authors is what made postcss-preset-env popular.
• providing polyfills is a completely different problem than providing "future css". Mixing these is a mistake imho.
• "vendor prefixing" features might help (@csstools-custom-media).
• our dependencies (node, PostCSS, ...), specifications and stylesheet changes all move at different speeds. It is too common that users create a setup once and then don't dare to touch any part because it might require them to rewrite their CSS source.
• browsers are moving away from vendor prefixes and are using experimental flags instead.
• users of postcss-preset-env might choose stage 0 because they want productivity tools without fully understanding how unstable these features are.
• providing plugins for "future css" is handy for spec writers and stylesheet authors to get a feel for a feature before real implementation starts.
• stylesheet authors have a habit of trial and error style coding (this is a good thing) but when there is a tool in the middle that is mutating CSS incorrectly we are "teaching" incorrect things to authors

[romainmenke]

rough proposal :

• we will not add a plugin to postcss-preset-env before CSS WG invites implementations
• we will not create plugins with features that look and feel native but don't have a spec (jquery :has() issue)
• we will only implement that which we know is correct and avoid side effects