- From: Romain Menke via GitHub <sysbot+gh@w3.org>
- Date: Sat, 01 Apr 2023 08:25:47 +0000
- To: public-css-archive@w3.org
> I'm being very firm here for a reason - it's incredibly hostile to all other parties to attempt to unilaterally thrust an early, unstable version of our work into "frozen in practice" stability. The browsers all have explicit steps in their launch processes for seeking and ensuring consensus and stability, and advance without those guarantees very carefully and deliberately. PostCSS and related tools do not meet that bar. I strongly agree with this and have added [some guidelines](https://github.com/csstools/postcss-plugins/blob/main/AUTHORING_GUIDELINES.md) to prevent this going forward. It is ok for anyone to create a tool to play around with a proposed feature before implementation, it is not ok for a tool to act as if these are ready for use before they ship in actual browsers. It think it is even worse that what you are describing. By going ahead of browsers we also shape the perception of a feature before it is ready. Every poll to gather CSS Author feedback around nesting was biased because of PostCSS Nesting and similar tools. ----------- My argument wasn't that some random PostCSS plugin should be given equal or similar weight as a browser implementation. Only that we "obfuscate" adoption of a feature in source code by transpiling it. But I agree that this is actually a good thing in this scenario. Real usage in browsers will be extremely low because anyone not writing a demo on nesting itself will use a transpiler. And these tools, as you said, have semver, ... ----------- _hehe, this escalated nicely, sorry about that :)_ -- GitHub Notification of comment by romainmenke Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8662#issuecomment-1492877209 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 1 April 2023 08:25:49 UTC