)<\/span><\/small><\/pre>\n\n\nIn Sass, that doesn’t compile to anything. You have to use it. Like:<\/p>\n\n\n
.modal-overlay<\/span> {\n<\/span><\/span> @include<\/span> cover;\n<\/span><\/mark>}\n<\/span><\/span>\n<\/span><\/span>.card<\/span>.disabled<\/span> {\n<\/span><\/span> &::before<\/span> {\n<\/span><\/span> @include<\/span> cover;\n<\/span><\/mark> background<\/span>: lch(0%<\/span> 0<\/span> 0<\/span> \/ 0.8<\/span>);\n<\/span><\/span> }\n<\/span><\/span>}\n<\/span><\/span><\/code><\/span>Code language:<\/span> SCSS<\/span> (<\/span>scss<\/span>)<\/span><\/small><\/pre>\n\n\nSee how I’ve used it twice<\/em> above. Compiled Sass will dump in the contents of the mixin in both places:<\/p>\n\n\n.modal-overlay<\/span> {\n<\/span><\/span> position<\/span>: absolute;\n<\/span><\/mark> inset<\/span>: 0<\/span>;\n<\/span><\/mark>}\n<\/span><\/span>\n<\/span><\/span>.card<\/span>.disabled<\/span> {\n<\/span><\/span> &::before {\n<\/span><\/span> position<\/span>: absolute;\n<\/span><\/mark> inset<\/span>: 0<\/span>;\n<\/span><\/mark> background<\/span>: lch<\/span>(0%<\/span> 0<\/span> 0<\/span> \/ 0.8<\/span>);\n<\/span><\/span> }\n<\/span><\/span>}\n<\/span><\/span><\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\nThings can get a little fancier in Sass, but it’s all pretty straightforward:<\/p>\n\n\n\n
\n- Mixins can include nesting and work in nested code. They can even slot in nested content you pass to it.<\/li>\n\n\n\n
- Mixins can use other mixins. <\/li>\n\n\n\n
- Mixins can have parameters (like a function) and use\/calculate off those values in the output.<\/li>\n<\/ul>\n\n\n\n
I would assume and hope that all of this is supported in native CSS mixins. The native version, as explained so far on Miriam’s site (which will almost definitley change!), the only difference is the usage syntax:<\/p>\n\n\n
@mixin<\/span> --cover {\n<\/span><\/mark> position<\/span>: absolute<\/span>;\n<\/span><\/span> inset<\/span>: 0;\n<\/span><\/span>}\n<\/span><\/span>.modal-overlay<\/span> {\n<\/span><\/span> @apply --cover;\n<\/span><\/mark>}\n<\/span><\/span><\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\nI imagine it’s @apply<\/code> instead of @include<\/code> literally because Sass uses @include<\/code> and Sass would have a hard time “leaving it alone” when processing down to CSS.<\/p>\n\n\n\nIs there enough here for browsers\/standards to actually do it?<\/h2>\n\n\n\n
The W3C CSS Working Group has already OK’d the idea of all this, so I assume it’s already been determined there is value to native CSS having this ability at all. But what are those reasons? <\/p>\n\n\n\n
\n- Not having to reach for a preprocessor tool like Sass.<\/strong> I don’t think this is enough of a reason all by itself for them, but personally, I do. This is a paved cowpath, as they say.<\/li>\n\n\n\n
- Preprocessor output has potentially a lot of duplicate code.<\/strong> This leads to bigger CSS files. Perhaps not a huge issue with gzip\/brotli in play, but still, smaller files is almost always good. <\/li>\n\n\n\n
- Integration with
--custom-properties<\/code>.<\/strong> I would think the parameters could be custom properties and there could be custom properties used generally with the style block. Custom properties can change dynamically, causing re-evaluated styles, so mixins can become more powerful expressions of style based on a comparatively small custom property change. <\/li>\n\n\n\n- Custom Properties can cascade<\/strong> and be different values at different points in the DOM, so mixins might also do different things at different points in the DOM. All this custom property stuff would be impossible in a preprocessor.<\/li>\n\n\n\n
- It’s a nicer API than faking it with
@container style()<\/code><\/strong>. You can test a custom property with a style query and dump out styles in certain places now, but it doesn’t feel quite right.<\/li>\n<\/ul>\n\n\n\nI wonder what else tipped the scales toward the working group doing it.<\/p>\n\n\n\n
Parameter handling seems tricky.<\/h2>\n\n\n\n
You can pass things to a mixin, which I think is pretty crucial to their value.<\/p>\n\n\n
@mixin<\/span> --setColors(--color) {\n color<\/span>: var<\/span>(--color<\/span>);\n background-color<\/span>: oklch<\/span>(from<\/span> var<\/span>(--color<\/span>) calc<\/span>(l<\/span> -<\/span> 40%) c<\/span> h<\/span> \/ 0.9<\/span>);\n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\nBut things can get weird with params. Like what happens if you call setColors()<\/code> with no params? Does it just fail and output nothing? <\/p>\n\n\n.card<\/span> {\n @apply --setColors();