Foundation 5.4.5 (Compass stack) issues #443
The latest Compass-compatible build of Foundation (5.4.5) seems to be incompatible with CodeKit's internal version of Compass.
I've only just started to unravel the compatibility nightmare that is Foundation 5.4.5 - but I get the following message when I create a new Zurb Foundation with Compass project in CodeKit...
The lines in question were added in Foundation 5.4.5 (Compass version) along with a gem file that is supposed to allow Compass compiling through Bundler (and some additional dependencies - ugh). Here are the lines in question...
I'm starting to think that Compass is on it's way out in Foundation, considering the popularity of libsass and the fact that Zurb is giving libsass preferential support over Compass... but I thought I'd get this logged here since this might turn into a bigger issue.
Also, deleting those checks in
The text was updated successfully, but these errors were encountered:
"Unraveling the nightmare" is exactly the right expression. Here's the rundown:
The official Ruby Sass team recently released version 3.4, which is what’s included with the latest version of CodeKit. Sass 3.4 introduces some syntax changes that are backwards-incompatible.
Zurb updated Foundation to support Sass 3.4, but that broke compatibility with Sass-Rails and the Libsass compiler (neither of which currently support Sass 3.4+ syntax). So, Zurb rolled Foundation back and now require you to use the older Sass 3.2 or 3.3 compilers and Compass < 1.0.
How This Affects CodeKit
Installing Foundation WITH Compass requires you to delete those bottom lines from the
In my own testing with the official CodeKit website (which is built on Foundation and compiled with Libsass), I found that several things broke when I updated Foundation to the latest release and then compiled using the Sass 3.4 Ruby compiler (Libsass could not compile the latest version of Foundation correctly because it uses newer Sass syntax.) Little things like hamburger menus, etc did not come out correctly.
You can, however, create a new Foundation project WITHOUT Compass and CodeKit will compile it just fine as long as you flip on the Libsass compiler for your Sass files.
How Zurb Should Handle This
The CORRECT solution is to issue (and maintain) multiple forks of Foundation:
This is a lot of work for Zurb, so I see why they don't want to do it. I don't blame them for simply saying, "Use older Sass until the Sass team(s) fix this mess."
The Real Problem
The official Ruby Sass compiler keeps advancing, introducing new features and backwards-incompatible syntax changes. Libsass, however, always lags Ruby Sass. Libsass is still trying to get all the features and syntax of Sass 3.2 implemented correctly, let alone the new stuff in 3.3 and 3.4!
But Ruby Sass is excruciatingly slow. It's the ONLY major compiler that's still written in Ruby. (Other than Haml and Slim, which are primarily targeted at folks running Ruby on Rails anyway). Ruby is never going to be fast. As long as the official Sass compiler is in Ruby, it will always be slower than the competition (Less and Stylus).
But until we convince the entire Sass team of that, we're going to be in for some choppy times as major framework vendors struggle to support both cutting-edge features in the Ruby Sass compiler AND Libsass.
The Big Risk
If Sass remains fractured in this way, I suspect many framework vendors and web developers will take a closer look at Stylus, by @LearnBoost. It's come a long way and, like Sass, is now a superset of the CSS syntax, meaning you can write 100% normal CSS and simply add in the parts of Stylus that you like. A great example is http://jeet.gs by @mojotech, which offers a Sass and Stylus version.
Zurb Foundation is hardly the only project facing this current mess. Bourbon, Bourbon Neat and many other popular frameworks are currently maintaining two versions: one for Ruby Sass and one for folks that want to use Libsass.
If the official Sass team drags this out for years, Sass risks folks jumping ship to languages that aren't fighting over what their future should be. In my opinion, Sass has built a strong advantage by courting vendors like Zurb, who build popular frameworks based on the language. But those vendors are only going to put up with this giant mess of Ruby/Libsass for so long before they leave for more stable platforms.
The Long-Term Solution
Ultimately, in my opinion, the best solution is to bring Libsass up to 100% feature parity with Ruby Sass and keep it there. Libsass should take over the title of "official" or "canonical" Sass and all future development of the language should happen there. The Ruby compiler should transition to a thin wrapper that simply calls the Libsass binary (just like the Libsass CLI is just a thin node.js wrapper).
This is the outcome that is best for Sass users, major Sass vendors (like Zurb) and the future of Sass itself.
I've considered launching a kickstarter to give the Libass team the resources to hire more than one guy to bring the tool to parity with Ruby-Sass, but I'm unsure what the community response would be.
Also, regarding "compass on the way out" --> Right now, Compass is not compatible with Libsass. But the author of Compass, @chriseppstein, is one of Libsass's biggest proponents. He's committed to making Compass compatible with Libsass in the future.
I don't think the Zurb team dislikes Compass. Rather, they simply want to use the fast compiler.
Also, I'm debating how to handle this situation in CodeKit. The options appear to be:
It is NOT an option to keep CodeKit on Sass 3.2 for the next six months. Folks that don't use Foundation want the latest version of the Ruby Sass compiler.
It's also not an option to let folks switch to an OLDER version of the Sass compiler as an external compiler in CodeKit because the Ruby Sass team changed the damn CLI interface so that the commands CodeKit passes to Sass 3.4 will fail on Sass 3.3-. (Ugh.)
Like I said: "Unraveling the nightmare" is the correct phrase.
@bdkjones, these are my thoughts exactly, and thanks for being sympathetic to our troubles :) It was our mistake to even try supporting Sass 3.4 at all, and now that we're rolling back we have to do a bit of damage control. As far as our preference, we don't really have one. The Compass stack is still the default if you use our CLI, but increasingly we're using the libsass stack for client projects.
In theory if our codebase was split, for our specific needs we would only need two:
There are two ways to look at libsass:
It's too late for option 2; libsass is only growing in popularity, and people aren't going to accept it has a "nice to have", compatibility-wise. The support needs to be there for major libraries like ours, it would seem. But as you've already articulated, the feature gulf is only going to get wider.
Bryan, in regards to your hypothetical CodeKit options, my vote is for option one - or a feature like it.
I'd be wary of automatically using an older version of Ruby Sass for Compass projects with no way to override that in the event of hypothetical future breaking changes... but speaking purely out of selfishness and personal preference, it would be tremendously useful if CodeKit bundled multiple versions of Ruby-Sass and let me select which to use on a project-by-project basis.
It's definitely less than ideal, but considering the muddy situation right now with Sass and projects that depend on it, it would be the most flexible and reliable solution for the time being.
Another quick thing on our end, right now we won't support Sass 3.4 until:
Support for a fake
As it turns out, the changes in variable scope don't really affect our codebase. It's the mere existence of
Yea. CodeKit is currently using the latest
In practical terms, you can install Foundation WITH Compass in CodeKit 2.1.6, comment out the lines you guys added at the bottom of the config.rb file, and then use Ruby Sass 3.4 and Compass 1.0.1 to compile --- it does work. But I don't know the edge cases where this will fail. What CSS classes are generated incorrectly?
@gakimball Also, it would GREATLY help if you guys could update that extra bit in the config.rb file to first test for the existence of an installed Sass gem before you try to call it to see what version is installed. Right now, you're just assuming that the Sass gem is installed on the system, which it won't be for folks that use an app like CodeKit (or any of my competing apps) to compile.
@bdkjones Ah okay, yep we can do that. Or can we change it to check against the version of the library itself rather than the Gem? I don't write much Ruby, but if we can check like this:
Then that's guaranteed to always be there, right?
The idea behind the check was just to inform 3.4 users of what's going on. We should have had a Gemfile in there from the beginning, and been telling users to use
I just installed Foundation 5 with Sass on Ubuntu 14.04, yesterday, and followed the instructions on zurb.com's website. The styles do not work at all! This set-up seems to be too complicated for it to work properly; to many dependencies. It increases the likelihood for things to break.