Content functions.

I’d like to introduce a function content() that returns a Sass data structure that represents the css specified as mixin content that is normally placed by the @content directive. The exact form of this data is something that would need to be well specified, I will work on that if people are in agreement that this is a good idea.

I also think Sass should provide a mixin that effectively translates this data back into CSS. E.g. @include expand-content(content()); would be identical to @content; when used inside a mixin. Sass doesn’t currently expose any mixins automatically so we probably just want to make a special import location so that Sass mixins can be manually imported if they are needed. @import 'stdlib' or something?

Here’s the rationale. I see a lot of users clamoring to use SassScript to manipulate their CSS. To do this, they end up defining their CSS as maps instead of as CSS. I’d like things that are stylesheets to be specified in CSS syntax, not in some it’s a map and it’s almost css syntax just so that it can be manipulated.

Another use case is that, https://github.com/oddbird/true needs a way to verify that the output of a mixin is correct without relying on string-based output comparison tests. By providing this capability, the css output of a mixin can be tested using SassScript.

In the past, I’ve proposed special directives to accomplish this, but I don’t think that’s necessary.

[cyraid]

How hard is it to say “still working on it guys” or “we haven’t started on this because other issues are more important”… then maybe a voting system could be used to see what is more important.

Besides, it’s been 4 years since the issue was created, and a year since any communication on the topic. It looks like abandonment to some, so ‘bumping’ it after that long for a status update I didn’t think would be so terrible. Would someone really reply after a year after seeing a thumbs up? Don’t think so.

[nex3]

How hard is it to say “still working on it guys” or “we haven’t started on this because other issues are more important”… then maybe a voting system could be used to see what is more important.

Sass language design isn’t a democracy. We do consider user demand (based on number of 👍s) when prioritizing issues, but we also consider many other factors. Again, we have very limited resources, and responding individually to every “Any update?” comment takes up those resources.

If someone is particularly interested in making a feature happen, they’re encouraged to spend their own resources on helping to make that happen. But you don’t get to insist that we allocate our resources on the features you want, or on responding to your comments in the way you want.

Besides, it’s been 4 years since the issue was created, and a year since any communication on the topic. It looks like abandonment to some, so ‘bumping’ it after that long for a status update I didn’t think would be so terrible. Would someone really reply after a year after seeing a thumbs up? Don’t think so.

That’s how most projects work. We use the issue tracker to track features we’d like to get to someday, which means that they can stay open with relatively little change for a long time.