4 ms·
For me this is where something like PostCSS shines. You simply write future css and remove the plugin when it’s supported natively. This wins in my opinion bec
by amjnsx 4y ago
For me this is where something like PostCSS shines. You simply write future css and remove the plugin when it’s supported natively.
This wins in my opinion because there shouldn’t be any conversion necessary from something like Sass to CSS
- tehbeard 4y agoWhat's the hit/miss rate on that CSS changing syntax? I Vaguely recall something similar happening with decorator syntax/how it worked in JS/typescript. Or do you keep to CSS features that are locked down in terms of spec, just waiting on implementation to roll out?
- amjnsx 4y agoIt’s your call fortunately/unfortunately. The safe option is obviously to install plugins for features that are close to passing as possible, where the api is stable at least - but there are plugins for very early stage proposals too.
- nobleach 4y agoThat decorator syntax thing was a mess. The original syntax seemed like it was far enough along. Many folks adopted it because it seemed like "a sure thing". I ended up pulling it from a project in 2017 because so few of the folks on my team wanted to truly understand what problem those were meant to solve. It was easier to "decorate" in a more manual way (wrapping a function with a function). The way TC39 handles stages now should stop things like that from happening. (You implement a Stage 1 or 2 feature fully knowing it could change)