3 ms·
I don't think what you describe is actually the goal of this proposal. I don't think anyone involved in the standards-making is looking at how many bytes of CS
by jrochkind1 4y ago
I don't think what you describe is actually the goal of this proposal.
I don't think anyone involved in the standards-making is looking at how many bytes of CSS would be saved -- I don't think the number is likely to be significant to anything, and I don't think this is the motivation.
My understanding is that the intention is really to make CSS pre-processing less necessary, take features that people have found the need to have preprocessors for, and put them in the standard so the preprocessors aren't necessary for those features.
I feel like I've seen some of the undesirability of preprocessors in my experience with sass/scss, which is having to make backwards incompatible changes in order to avoid conflicts with the evolution of CSS underneath it. Also just having to setup the pre-processor can actually be a significant infrastructure burden -- Rails had to kind of completely change how it supported SCSS when SASS moved to supporting dart-sass as essentially it's only supported implemnetation (no more libsass or ruby-sass). And then what happens when one of your dependencies uses scss and another uses postcss. I understand the desire to get back to not using pre-processors.
You can definitely have your own goals and motivations and encourage people participating in this user poll to adopt them too. But if they aren't the goals the committee is working towards, they're unlikely to be achieved very well... and there are probably reasons they aren't.
- okonomiyaki3000 4y agoI believe your understanding of the intention is correct and I totally agree with what you're saying about those involved in creating the standard. I just don't think they'll be able to evolve CSS into something preferable to using a preprocessor for many many years if ever.