3 ms·

Don't try to imagine yourself writing this code. You won't have to. We have preprocessors and they'll always be better than writing plain css. One of these stan

Don't try to imagine yourself writing this code. You won't have to. We have preprocessors and they'll always be better than writing plain css. One of these standards will be what preprocessors of the future will need to write. The result will be that your compiled css will be smaller than what is possible with today's standard. So don't choose the option that's easiest for you to write, choose the one that's small.

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 ago
  I 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.
LocalPCGuy 4y ago
Totally disagree with this sentiment (that CSS will always need to be pre-processed). In many cases today it isn't necessary, even for fairly complex projects. This (nesting) is one of the last issues that causes me to reach for a pre-processor, honestly. So (IMO) we should absolutely be looking for what makes the most sense for human devs to write and read, and that should be the default for the base language that the browsers can interpret. We can always make it smaller via minification, etc.

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 ago
I 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.

LocalPCGuy 4y ago

Totally disagree with this sentiment (that CSS will always need to be pre-processed). In many cases today it isn't necessary, even for fairly complex projects. This (nesting) is one of the last issues that causes me to reach for a pre-processor, honestly. So (IMO) we should absolutely be looking for what makes the most sense for human devs to write and read, and that should be the default for the base language that the browsers can interpret. We can always make it smaller via minification, etc.