The problems with Sass were clear. At the same time, the new CSS specs were very clear and worth noting. We tried to go back to pure CSS in light of this, but we ended up staying with it, so here's a summary of the process.
This is how it was for me personally and the team. I think everyone is different in this area.
@extendto share styles
@mixinto share vendor prefixes (though recently I've been using autoprefixer), define style rules, share breakpoints, etc.
Functions that are not used are also preset. If we as a team don't clarify the criteria of which features we want to use, there is a high possibility that newly joined members will use every single feature and make the review process difficult.
In addition to Dart Sass, Sass: Embedded Sass is Live
Sass has a pragmatic policy that allows the specification to change to match CSS design theory that is considered useful in the real world. The following features are in the process of being deprecated and will require changes to past code
@import allows access to style conventions even when
@import is used in a hierarchical manner, but this specification began to be seen as problematic, and
@use was adopted as an alternative. This means that the style conventions can only be accessed in the file that invokes them.
In CSS, there is a property that uses
/ as a delimiter.
In this case, Sass cannot distinguish whether the
/ is a delimiter or a divisor. As an alternative, we recommend
Sass: Breaking Change: Slash as Division
cssdb - CSS Database defines stages** to standardization of new features, called **stages**.
|Stage|Level|Maturity Level| |:--:|:--:|:--:|Stage3 |Stage4|Standardized|High |Stage3|Embraced|: |Stage2|Allowable|: |Stage1|Experimental|: |Stage0|Aspirational|Low
It seems that as the Stage goes up, the browser support actually improves. Also, [postcss-plugins/plugin-packs/postcss-preset-env](https://github.com/csstools/postcss-plugins/tree/main/plugin-packs/postcss- preset-env) allows you to comply with this stage and use features that will be standardized in the future.
It seems that there are quite a few features that we used to use in Sass.
|nesting||nesting rule (stage 1)||postcss-nesting|
|color reuse||custom property (stage 3)||postcss-custom-property|
|reuse media query||custom media query (stage 2)||postcss-custom-media|
|class inheritance||under discussion||postcss-extend|
|Mixin||under discussion 1||postcss-mixins, postcss-apply|
Please do some research on the notation of each rule.
The stage defined by W3C is not an official release version and its use is less stable. Low stage must also be taken into account that the specification is more likely to change or be REJECTED. Before one has little knowledge or experience with draft CSS, it is better to follow the default (stage 2) of postcss-preset-env.
For example, the nesting rule is still in stage 1, so the specification is likely to change. If you implement it in postcss-preset-env, you may have to re-implement just the nesting part later.
It may still be too early to adopt postcss-preset-env after all the above discussion. From now on.
I think that is what I was thinking. Thank you very much.
@apply is being discussed, but apparently there are technical issues that are making it difficult. ↩