Change Stage Decission

[Antonio-Laguna]

This is a breaking change but we think this paints a more accurate picture.

[Antonio-Laguna]

@romainmenke let's use this to openly discuss. IMHO we should rely on the current text no matter whether it's a recommendation or even a draft.

[romainmenke]

this is all my opinion and I do not have any strong feelings about this in any direction

---

Currently the stages mix spec status and implementation status, which might be fine.
But I think we fail to communicate the underlying issue/challenge.

I am making assumptions here and maybe we should do a poll to check this?
But I fear that too many people set the stage to get the features they want from postcss-preset-env.

Any CSS written for plugins that transform against unstable specs is in a sense technical debt.
You might get lucky on a couple of features, but most will require you to make source code changes at some point.

So it can be abstracted to :

• I can not or do not want to update my source code with the next postcss-preset-env major release.
• I can handle a few changes in the event that a feature already implemented by multiple browsers changes unexpectedly.
• I can handle the technical debt
• I will never update postcss-preset-env (not advisable but a real world case)

https://cssdb.org/#staging-process

An Unofficial Draft or Editor’s Draft championed by a W3C Working Group Member. It should be considered highly unstable and subject to change. Stage 0 features are open to ideas and discussion, but may not be considered serious.

From this statement alone it is difficult to judge what will be required from the end user if the spec changes.

Having it literally say something like this would be better :

If a specification changes we will have to update the relevant plugins to match.
This will require you to update all CSS source code for this feature when updating to the next version of this plugin.

Having a guide for "which stage fits you" with some Q/A would be best.

---

At the moment I would say that specification status is irrelevant to the choice the end user of postcss-preset-env has to make.

Having a simplified model based only on browser implementation status would be easier to understand.

[jonathantneal]

I like the idea of communicating the impact of staging to users. One thing to consider is that CSSDB cannot be explicitly tied to PostCSS Preset Env, since PostCSS plugins cannot interact with a living DOM tree. This means details for :has and @container would be helpful and comfortable to include in CSSDB, but less comfortable to include in PostCSS Preset Env.

All this means is: I would recommend language not explicitly tied to PostCSS Preset Env. Maybe something like this?

Before:

Stage 0: Aspirational
If a specification changes we will have to update the relevant plugins to match.

After:

Stage 0: Aspirational
This feature should be considered highly unstable and subject to change.
Polyfill authors and polyfill users should expect significant changes to their codebase as the specification evolves.

[romainmenke]

Good catch! That is a better way to formulate this here

[Antonio-Laguna]

Following #60 here's the initial things that change spec:

Stage change for any-link-pseudo-class 2 -> 3
Stage change for case-insensitive-attributes 2 -> 3
Stage change for environment-variables 0 -> 3
Stage change for focus-within-pseudo-class 2 -> 3
Stage change for hexadecimal-alpha-notation 2 -> 3
Stage change for in-out-of-range-pseudo-class 2 -> 3
Stage change for is-pseudo-class 2 -> 3
Stage change for logical-properties-and-values 2 -> 3
Stage change for not-pseudo-class 2 -> 3
Stage change for overflow-property 2 -> 3
Stage change for overflow-wrap-property 2 -> 3
Stage change for overscroll-behavior-property 1 -> 2
Stage change for prefers-color-scheme-query 1 -> 3
Stage change for prefers-reduced-motion-query 1 -> 3
Stage change for read-only-write-pseudo-class 2 -> 3
Stage change for rebeccapurple-color 2 -> 3
Stage change for system-ui-font-family 2 -> 3