Intentions for cssdb 6x
jonathantneal opened this issue · 0 comments
Breaking changes are coming to cssdb and they impact PostCSS Preset Env. I appreciate your thoughts.
TL;DR
- The cssdb semver strategy is not changing.
- The cssdb staging strategy is changing. Things advance faster when they ship.
Changes
At present, cssdb has used this strategy:
| Stage | 0 | 1 | 2 | 3 | 4 |
|---|---|---|---|---|---|
| W3C Status | Unofficial Draft or Editor’s Draft |
Editor’s Draft or Working Draft |
Working Draft | Candidate Recommendation | Recommendation |
| Browser Implementations | 0+ | 0+ | 0+ | >= 2 (even behind a flag) | >= 4 |
In this existing strategy, the stage has required both the W3C Status and the number of Browser Implementations to be fulfilled.
Moving forward, cssdb would use this new strategy:
| Stage | 0 | 1 | 2 | 3 | 4 |
|---|---|---|---|---|---|
| W3C Status | Unofficial Draft or Editor’s Draft |
Editor’s Draft or Working Draft |
Working Draft | Candidate Recommendation | Recommendation |
| Engine Implementations | < 2 | < 2 | >= 2 | >= 3 | >= 3 |
In this new strategy, the stage would require either the W3C Status or the number of Browser Implementations to be fulfilled.
Additionally, tracking would change from Browser Implementations to Engine Implementations. The implementations would be Blink, Gecko, and WebKit. This means Brave, Chrome, Edge, and Opera would all count toward only 1 implementation.
Why is cssdb changing the strategy?
The strategy is changing because there are now only 3 distinct browser engines with a significant number of users in development; Blink, Gecko, and WebKit. At this time, I am unaware of any further development being put into Presto, Trident, or EdgeHTML. While the number of engines might change again in the future, making this change in the next major version of cssdb is intended to be prudent.
Citations:
Why is cssdb changing the number of required implementations?
The number of required implementation is changing to better reflect real-world compatibility. The remaining 3 browser engines and the W3C seem to agree and match one another in public APIs, while keeping experimentations behind experimental flags.
Citations:
- https://developers.google.com/web/updates/2018/03/smooshgate#break-the-web
- https://developer.mozilla.org/en-US/docs/Glossary/Vendor_Prefix
- https://www.w3.org/TR/html-design-principles/#support-existing-content
How do these changess to cssdb affect PostCSS Preset Env?
These changes to cssdb would have a big impact on what PostCSS Preset Env transforms.
Consider that any feature in Editor’s Draft or Working Draft is stuck in Stage 0 or Stage 1, regardless of the number of implementations. Moving forward, that same feature in Editor’s Draft with 2 implementations is Stage 2, while in Working Draft it is Stage 3, the stage enabled by default. The intention of this change is to honor the promise of cssdb is to be a comprehensive list of CSS features and their positions in the process of becoming implemented web standards.
As a significant side benefit, these changes will make it easier to calculcate the status of features with scripting.