New BT and compass

[mauritslamers]

Perhaps this issue can be best put at the sproutcore repo, but there is a (already known) existing problem with NodeJS and non-ruby compass support, in the sense that there isn't any.

In the sass_slicing branch (https://github.com/sproutcore/build-tools/tree/sass_slicing) I have moved in the sass and slicing support originally written for garçon. This branch however crashes because sass doesn't understand the compass extensions. In garcon I worked around it by just filtering everything out sass couldn't understand, and just inserting all the compass extensions written in sass/scss. However, this is not a full replacement, because compass also extends the ruby part of sass/scss which cannot be replicated directly into nodejs.

My question here is: What parts of compass do we actually use in sproutcore and in what way do they rely on the ruby extension of compass? How easy would it be to do a kind of workaround to have the same effects without actually using compass?

[dcporter]

Do a global find for "@include" in SC, and scan for all items that don't start with "@include slice". I see border-radius, transform, transition, and box-shadow. I could be wrong, but I don't believe SC itself uses any other parts of Compass, and I would be surprised if any SC-based projects did.

Clearly the preferable solution would be to build a compass port that worked with lib-sass, as I'm confident that it would get buy-in from all over the web. However, I'm not sure anybody has time to spearhead that effort.

So, since we're already supporting the custom "@include slice" & "@include slices" commands, I don't see it as a huge deal to add support for a few others that we maintain ourselves. I'm comfortable listing "full compass compatibility" as a feature that gets left behind in (the still available, still usable) abbot.

[mauritslamers]

To clarify: which of those commands are actually sass, and which are compass? I have no experience in either of those languages and very little experience with css in these kinds of circumstances, so detecting which is which is the hard part.

If I would have an example on what the input would be as well as the intended output, I could try to do some text manipulation in order to get the desired result, or try to bake some functions in scss to get what we need.

BTW there is an active bounty for having compass on top of libsass here: https://github.com/hcatlin/libsass/issues/82

[dcporter]

I understood "@include" to be chance or compass, not sass, 100% of the time. I could be wrong.

[mauritslamers]

@include itself is valid sass: http://sass-lang.com/documentation/file.SASS_REFERENCE.html#including_a_mixin

One of the problems sass chokes on is that it tries to include compass, which doesn't exist. In the garcon versions I managed to get around that by creating a simple nodejs module which returns all the sass extensions and definitions of compass and return it as one big string (https://github.com/mauritslamers/compass) and then do a simple replace for @include 'compass/css3'. I haven't done that in this case (yet) and it doesn't solve all of the problems sadly.

[dcporter]

But all of the mixins we use are from outside sass, right? Chance + Compass. My understanding is that the slice and slices mixins are from Chance, and the rest are from Compass.

(Agreed that the garçon approach is the wrong one.)

[mauritslamers]

What chance does, has nothing to do with sass or compass: it is "fake" compass/scss to comply with the syntax of the rest, but it is just replaced in place with either a relative url to an image file or a data uri. After that it is forwarded to compass to do the rest of anything with "real" css.

[mauritslamers]

Update: as from commit f07a4c1 (which includes code from the garcon-based buildtools) on branch compass_ruby, the preparation of themed css files will now cause "compass compile" not to give any errors. Which doesn't mean necessarily that the css is correct, but it means that the parsing of @theme(name) { }, injecting $theme: themename and replacing $theme. by #{$theme}. works correctly. In this commit a manual compile is still required, and files are not yet re-read into the buildtools.

[mauritslamers]

and from commit b93d361 things are read back into the build tools. Implemented mainly to also find out how this kind of support can be added if people would want to. (plugins which are not plugins).

[mauritslamers]

As compass parsing is now native in the build-tools, I am closing this issue as being fixed. If anyone encounters something not picked up by the internal replacer, please open a new issue.