Yes, I've seen this bite people a couple of times now. I'll make a fix.

Print a message when updating a project that has no files. They probably meant to install but forgot the directory argument. Closed by 15ebbfe.

This is a Sass bug that has been fixed. You need to upgrade to haml-edge:

sudo gem uninstall haml
sudo gem install haml-edge

I have both running actually... will this mess with my environment if I don't use haml-edge for other projects but use haml? I guess I'm not clear on the diff btwn these releases...

You can just download and install the latest from haml's master branch, that is what haml-edge is. Compass will try to pick up haml-edge if it's installed, but YMMV.

[Rails] Don't set the output style in the compass.config file for rails projects. It will default according to the runtime environment. Closed by 7b90aef.

Please double check that you are running the latest version of haml. If it still happens, please post the full stack trace

Here's what I get.

C:\>haml -v
Haml 2.0.9

C:\>compass -f blueprint sample-project --trace
directory sample-project/
directory images/
directory src/
directory stylesheets/
   create config.rb
   create screen.sass
   create print.sass
   create ie.sass
   create grid.png
   exists stylesheets
  compile ie.sass
ArgumentError on line 18 of C: marshal data too short
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/files.rb:18:in `tree_for'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/file_node.rb:19:in `perform!'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:73:in `_perform'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:61:in `perform'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:82:in `perform_children'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:82:in `map'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:82:in `perform_children'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/file_node.rb:20:in `perform!'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:73:in `_perform'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:61:in `perform'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:82:in `perform_children'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:82:in `map'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:82:in `perform_children'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/file_node.rb:20:in `perform!'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:73:in `_perform'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:61:in `perform'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:82:in `perform_children'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:82:in `map'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:82:in `perform_children'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/file_node.rb:20:in `perform!'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:73:in `_perform'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:61:in `perform'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:82:in `perform_children'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:82:in `map'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:82:in `perform_children'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:78:in `perform!'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:73:in `_perform'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:61:in `perform'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:39:in `render'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/engine.rb:108:in `render'
  C:/Ruby/lib/ruby/gems/1.8/gems/chriseppstein-compass-0.6.6/lib/compass/actions.rb:68:in `compile'
  C:/Ruby/lib/ruby/gems/1.8/gems/chriseppstein-compass-0.6.6/lib/compass/compiler.rb:37:in `run'
  C:/Ruby/lib/ruby/gems/1.8/gems/chriseppstein-compass-0.6.6/lib/compass/compiler.rb:36:in `each'
  C:/Ruby/lib/ruby/gems/1.8/gems/chriseppstein-compass-0.6.6/lib/compass/compiler.rb:36:in `run'
  C:/Ruby/lib/ruby/gems/1.8/gems/chriseppstein-compass-0.6.6/lib/compass/commands/update_project.rb:19:in `perform'
  C:/Ruby/lib/ruby/gems/1.8/gems/chriseppstein-compass-0.6.6/lib/compass/commands/stamp_pattern.rb:19:in `perform'
  C:/Ruby/lib/ruby/gems/1.8/gems/chriseppstein-compass-0.6.6/lib/compass/commands/base.rb:15:in `execute'
  C:/Ruby/lib/ruby/gems/1.8/gems/chriseppstein-compass-0.6.6/lib/compass/commands/project_base.rb:19:in `execute'
  C:/Ruby/lib/ruby/gems/1.8/gems/chriseppstein-compass-0.6.6/lib/compass/exec.rb:197:in `do_command'
  C:/Ruby/lib/ruby/gems/1.8/gems/chriseppstein-compass-0.6.6/lib/compass/exec.rb:57:in `perform!'
  C:/Ruby/lib/ruby/gems/1.8/gems/chriseppstein-compass-0.6.6/lib/compass/exec.rb:40:in `run!'
  C:/Ruby/lib/ruby/gems/1.8/gems/chriseppstein-compass-0.6.6/bin/compass:8
  C:/Ruby/bin/compass:19:in `load'
  C:/Ruby/bin/compass:19

Compass requires edge haml (version > 2.1). You can install it from source, or using the "haml-edge" gem. Instructions are on the wiki.

More clear licensing. Closed by 99f608e.

Will be part of the 0.8 release.

[Command Line] Store sass cache files in the sass directory of the project. Closed by fcdaf41.

I agree that a change would be useful here to control the scoping of LI for nested lists. Please see my comment for more details.

Here's another try. Check out http://github.com/marnen/compass/blob/cf9050857adee8770d4b3a2a92322293c2ddc25d/frameworks/compass/stylesheets/compass/utilities/lists/_horizontal_list.sass .

[Compass Core] Extracted two new mixins from +horizontal-list. Closed by faadde2. The new +horizontal-list-container and +horizontal-list-item mixins can
be used to build your horizontal list when you need more control over
the selectors (E.g. when working with nested lists).

Thanks for your patches, but I decided to fix this using a different approach altogether This approach gives more control to the user when the default mixin doesn't work.

I assume your running a rails application environment. It's not "best practice" to check in your generated css in such environments. But assuming you do not agree with me, I still think it's incredibly dangerous to run with a different version of haml in development than in production. I recommend that you either freeze your haml-edge gem in vendor or install it in your production environment. Existing apps will be unaffected by the presence of the haml-edge gem, but compass will pick it up if it sees it.

I, too, look forward to the next stable release of haml so that we can simplify the dependencies. Hopefully it will be soon.

If you're only using compass in development, you can also do two other things:
1. Use compass in standalone mode without the rails integration. In an existing rails project, you can just delete the config/initializers/compass.rb and then run compass --watch to compile your stylesheets.
2. Conditionally run compass by wrapping the contents of config/initializers/compass.rb in a block that checks the current rails environment.

Thank you for the suggestions, I really appreciate it. I like the idea of Compass but if it depends on an edge version of something else and that dependency causes deployment problems then Compass isn't something that I would depend on in production. So thanks for the suggestions for ways to use it during development only. I solved my deployment problem by removing Compass from the project, since I don't have the option of removing the Haml gem from the deployment environment. If I continue to tinker with Compass then I'll just use it in development to trigger Sass. I do like that --watch feature.

You can reproduce the problem very easily. "gem install haml" Then try to run that sample Rails app. If you have both haml and haml-edge then Compass will load haml and then complain that it requires haml 2.1. If you have the ability to totally control what gems are installed in your production environment then that's no problem but Compass won't work on hosting environments that provide Haml and then don't let you mess with your GEM_PATH. That sounds like a niche thing but Dreamhost is one of those hosts and they're popular enough to be relevant.

I explicitly tested the case of having both gems installed, but I will retest. It shouldn't break if both are there and if that's the case, then a patch will be forthcoming. If it's not reproducible in a simple app with just haml and compass installed, then there must be something else that is requiring haml. Can you show me what your gem configuration in your environement looks like? It could be that you're setting the dependency incorrectly and causing the wrong version to get picked up.

I really appreciate your assistance, I know that you're a busy guy. I'm trying to repay Karma by contributing my own gem to the world for doing layouts, which will be compatible with Compass.

To start out my day today, I decided to add Compass back into that problem project that has to go to Dreamhost, to help you to troubleshoot any possible haml/haml-edge incompatibility. I re-ran compass --rails to add config/compass.config and config/initializers/compass.rb, and it WORKED. It deploys to the problem server and it runs. ZOMG now I'm so confused.

I think you can maybe mark this issue closed because I think maybe I was totally wrong. I'm going to continue tinkering with it today to try to reproduce the haml/haml-edge incompatibility that caused me so much grief last night.

Either way, Compass is really neat. Thank you for making it and for releasing it so that I can use it.

Looks like it was a haml versioning problem afterall. I removed some older installs and regenerated the compass files and it works now.

I can confirm this too. I just rebuild edge (0.6.12) to make sure I wasn't using an old version.

Btw, is there a way to add a patch to these issues?

I have already sent a pull request for http://github.com/marcenuc/compass/commits/5868c2e4e19ff2b0d12e326aaa6961f6674575ef

Fixed in 0.6.13.

I just did a gem install:

$ gem install haml-edge
Successfully installed haml-edge-2.1.16

That worked. Thanks. I guess then, the install doco needs to be updated to say this.

haml edge is hosted on rubyforge, some older versions of gem don't handle cross-server dependencies. By adding http://gems.github.com/ to you gem server list and not specifying --source for the gem install, you should have installation success. We should update the wiki and blog posts to reflect this, so I'm going to leave this issue open until they do.

I added http://gems.github.com/ to my gem server list, and I actually get

gem install haml-edgeERROR: could not find gem haml-edge locally or in a repository

Not sure whats going on.

haml edge is hosted on rubyforge. compass is hosted on github.

I have:

$ gem sources
*** CURRENT SOURCES ***

http://gems.rubyforge.org/
http://gems.github.com/

$ sudo gem install haml-edge --no-ri
Successfully installed haml-edge-2.1.24
1 gem installed
Installing RDoc documentation for haml-edge-2.1.24...

I don't have enough details to diagnose your issue.

I think this works, closing.

The plan is to host the stable gem there and the development gem on github. The account is a placeholder until I get around to it. Maybe I can do it for the 0.8 release.

Github gems are no more. I've since learnt that you can create 'prerelease' gems with a special version string:

http://rubygems.rubyforge.org/rdoc/Gem/Version.html

I'm changing all my old github gems back to normal syntax... ERROR: could not find gem compass locally or in a repository ;)

You could move it to Gemcutter instead. It should be a bit easier, and it seems like Gemcutter might take over gem hosting from Rubyforge.

The compass gem is already on gemcutter:

http://gemcutter.org/gems/compass

This is where I'll posting new releases.

Sorry, I see what the problem was now. I was trying to install 0.8.15, which does not exist on gemcutter. When I upped the version number everything worked.

after some tests, i found the problem is when the Compass try to touch the file (when detect identical content), after comment the line of touch the scripts runs without problems. The solution maybe is to create a touch implementation to deal with this problem.

It would be good if there was a patch that fixes this issue on windows that I could then test on unix based systems. I don't have easy access to windows.

The ruby implementation is supposed to work on windows. I'd like to have this bug reproduced by others before taking any action. Are you sure you don't have permission or some other issue that's causing the EACCESS error to be able to modify the file.

The issue is that, per
https://prototype.lighthouseapp.com/projects/8888/tickets/16-permission-denied-building-via-sprockets-on-windows, /> File.utime (called by touch) can't be run against a file that's
already open on Windows. I've created a patch that uses IO.read()
instead of File.new().read() to read in the existing file so that it
gets closed properly.

Patch at http://gist.github.com/140766

Fixed.

I suppose I should mention that the commit (in my fork) that fixes this is http://github.com/marnen/compass/commit/36f83511383fdd02be58b0a596a53080b0cb3861 .

I am having no issues with Safari 4. Perhaps you're mistaking !x and !y for the !width and !height (as in your patch), when they are actually for positioning the background image.

Works here: http://www.quicksnapper.com/files/9241/5712114684A3983E08A53A.png

Additionally, it seems quite easy to add width/height to the selector in the normal Sass fashion (I always do this) than to add more variables to the mixin.

You're right that I was a bit confused about the function of the !x and !y parameters, but even when I omitted them entirely, replace-text didn't work. I'll test again and report if anything changes.

Setting height and width and using 0 for !x and !y seems to have done the trick. I guess I'll just wrap that all in my own convenience function. Thanks for your advice here.

I added more comments to the mixin in the code.

instead of doing this:

@import blueprint.sass
+blueprint

I do this

@import blueprint/modules/grid.sass
@import blueprint/modules/utilities.sass
@import compass/reset.sass

+blueprint-utilities
+blueprint-grid

@beyoumedia is right, you can and should use the sub-mixins if you don't want ALL of blueprint

Thanks for filing this. I wasn't sure if there was already a way to override and I was just being dense.

I've created a patch here:
http://github.com/tdreyno/compass/commit/9b1f32bd9c9a147eab9e7030eb6c02bbee630a07

However, I don't actually agree with the concept. In my opinion, Compass should not contain any defaults and users would just use Sass normally to inject the colors and sizes like normal. The problem is, that's not how Blueprint is designed. It's designed to automatically have a very solid starting place for sites. This means sites using Blueprint with CSS have a lot of duplication thus the need for Sass & Compass in the first place.

I guess the defaults that are intrinsic to Blueprint muddle up the philosophy of Sass. Hopefully this patch makes people happy, but I can't help but think the increasing complexity is turning Compass into it's own weird language which will need more and more documentation as time goes on.

I agree. The main stylesheet provided by compass if you don't specify a framework is a reset and an empty file.

New frameworks built on Sass from the ground up are already under development and will be much more elegant to use. The compass core framework, tries to provide simple, basic mixins that are common patterns -- not anything that would make a site look presentable out of the box.

Thanks for the work, your thoughts on the matter are well founded, and your effort here is helpful.

There are also issues trying to override a:visited since it is set in the framework.

Perhaps a way to filter out rules on import?

@import foo.sass remove:"css selectors here"

right now I would have to fork the blueprint framework in order to fix this.

Or perhaps a rake task to "pull a snapshot of the framework into my app/stylesheets/framework" then I can tweak and periodically update if needed.

Overriding is easy, it's resetting or removing unwanted styles that's a hassle. I hate to inject more stuff into Sass itself, but maybe a - (minus) prefix to match the + (plus) prefix which removes information from the compiler's view of the sass structure. Obviously, I have no idea if that's even possible with the way Sass is implemented.

I knew I should have waited until the morning to post - I mean removing a:visited

Overriding is the way to go. The Sass compiler can trivially remove the duplication from the generated css in a future version. Maybe that should have been my response to the original request as well...

Fixed by b84dd30

Only happens if project is not initialized

fixed in 0.8

[Sass Extensions] Allow the asset host and cache busting strategies to be defined as part of the compass configuration. Closed by ef47f3d.

Sorry, this message was suposed to have a label #feature, but I don't know how to apply labels for messages. Perhaps is because I don't have permission.

I just realized that I can configure this on the "config.rb" file. Sorry. I didn't saw anything about the config.rb file in the wiki. Closing this message.

This feature is available in 0.8.

What version of haml do you have installed? This is likely because you have haml 2.0 and not 2.2 or haml-edge.

Yeah, I figured that out, but forgot to close this issue.

you have to run rake examples and it will build them for you.

ok thanks :)

[Blueprint] Fixed a bug in the calculations for the +colborder mixin. Closed by d2b1370.

Compass will continue to default to haml-edge if it is installed, but I will change the behavior to printing out a message only when it is used, not when it is missing.

Load haml-edge if it's all new and shiny. Closed by 59a6067.

oops, sorry. this is a dupe of #26

There's a similar comment in the compass implementation file, but perhaps one here would be more useful.

Indeed :)
Anyway, I don't which file you're mentioning, I don't see anything like that in frameworks/blueprint/_ie.sass ?

It's here:
http://github.com/chriseppstein/compass/blob/f8987b816531e2e9bc64c7a24e0c82d9ef34bfff/frameworks/blueprint/stylesheets/blueprint/modules/_grid.sass#L71

But your way is better.

merged. thanks.

I posted a revised forms.html.haml to the Compass google groups that should be useful for testing this once fixed. HTH.

That file is now part of the compass/examples/blueprint_default example. Now we just need a fix ;-)

Sorry it has taken me so long to get around to this but I've finally taken some time to look into these issues. It seems that the inline form mixin wasn't getting applied to form.inline in the example, so I've fixed that in the master branch of my fork.

This fixes the alignment of all of the elements except for the submit button, which for some reason is way up. I haven't been able to track it down but it's probably outside of _form.sass, since _form.sass doesn't contain any styles that directly affect the button. =(

Is there any update to this?

I haven't been able to solve it yet and I currently can't allocate time to look into it further. >_<

I applied Enrico's patch and then I poked around for a while. It's very strange. I can't find any CSS difference that matters. But I did find that I could make it render correctly if I added a non-breaking space.

http://github.com/chriseppstein/compass/commit/81942836d095a7a82fb4ddc966bb40eea6b9345b

I think it looks pretty good. If this issue is troubling others enough for them to find the root cause, I'd be happy to accept their patch/fix in any form.

It's pretty easy to make a new project using an existing setup:

mkdir new_project
cp old_project/config.rb new_project/config.rb
cd new_project
compass -f blueprint --install

Perhaps an example should be added to command line wiki page.

Regarding the project registry and related commands, I feel this might be too much complexity. A simple bash script could accomplish the same. Maybe I don't understand the use case...

http://github.com/ttilley is currently working on some multi-project thing called sassinator. Maybe it will meet your needs when he releases it into the wild.

This is fixed in edge already and will go out with the next release.

http://github.com/chriseppstein/compass/commit/7b28e9af4ab70b995239158a8c6a809c76184fa0

I think you need to upgrade. I fixed the bug a while ago and cannot reproduce it using Compass 0.8.7 [9aa9867]

$ compass --version
Compass 0.8.8 [6ae3f9a]
$ mkdir test
$ cd test
$ rails test
$ cd test
$ compass --rails -f blueprint .
...
Congratulations! Your rails project has been configured to use Compass.
Sass will automatically compile your stylesheets during the next
page request and keep them up to date when they change.
Make sure you restart your server!

Next add these lines to the head of your layouts:

%head
  = stylesheet_link_tag 'compiled/screen.css', :media => 'screen, projection'
  = stylesheet_link_tag 'compiled/partials/_base.css'
  = stylesheet_link_tag 'compiled/print.css', :media => 'print'
  /[if lt IE 8]
    = stylesheet_link_tag 'compiled/ie.css', :media => 'screen, projection'

(You are using haml, aren't you?)

I've had several reports that compass does work on windows. Please indicate the steps to reproduce this issue. What command are you running? What version of windows? Steps you followed to install compass?

Thanks

Hi, thanks for your feedback.

I finally spent some more time on this issue and find out a solution:

* Got to install ImageMagick manually (important: mark "add ImageMagick to system path" during install)
* You have to install RMagik gem manually on windows instructions a there http://rmagick.rubyforge.org/

best regards, Alex

closing. Hopefully google will help people find this issue if it affects them. Feel free to edit the wiki as you feel is appropriate.

I'm also getting these issues... Ruby 1.9.1p0
How long do we expect until this gets fixed?

Hi, I fixed my problem and pushed up to my own master fork http://github.com/priit/compass/tree/master (I made fork only for fixing this bug). By the way, the fix are already pulled to chriseppstein edge branch, so you can use edge or my temporary master branch. Cheers!

I release the fix for this in v0.8.12. Please let me know if you're having any more issues with ruby 1.9.1

seems to be working fine. sass files generate no problems.

:-D Great!

One less ruby 1.9.1 bug to deal with ;)

... Actually it all works pretty well: db drivers - 'kwatch/mysql-ruby' and 'qooba/sqlite3-ruby' being major needed updates. ... and tempfile problem with passenger: http://www.taylorluk.com/articles/2009/08/12/ruby-19-and-passenger

Anyway cheers, ;)

fixed in v0.8.9

With a better fix in 0.10.0 coming.

ok thanx ;)

Fixed here:
http://github.com/merbjedi/compass/commit/ad0cbee36bdc084871648705f3bd2203e3bbed78

merged to edge for the next release.

Actually, this one is still just a css class that is scoped by a paragraph... I changed the markup.

Now that we have Bundler, I think I can just make compass do a basic require of haml and leave what to load to the user...

grrrrr. Yes, that should write the file in binary mode...

Fixed in v0.8.10

I received a report that this bug still exists. Can you confirm or deny?

That the +inline-block mixin doesn't work on block elements in IE6 & 7 is a known issue. If someone gives a well tested solution that works across a broad array of both inline and block elements, I will accept that patch.

However, I would encourage you to revisit the choice to use a block level element, in many cases a span is more semantically correct for an inline-block based layout.

please test my fix that was posted to the newsgroup.

=inline-block 
  :display -moz-inline-box 
  :-moz-box-orient vertical 
  :display inline-block 
  :vertical-align middle 
  :#zoom 1 
  :#display inline 
  // fixes alignment against native input/button on IE6 
  :#vertical-align auto

This implementation was also posted:

=inline-block
  :display -moz-inline-box
  :-moz-box-orient vertical
  :display inline-block
  :vertical-align middle
  :#display inline
  // fixes alignment against native input/button on IE6
  :#vertical-align auto

Can someone please explain why the :#zoom 1 style is needed or not?

I found this post on the subject. They use conditional comments to target IE < 8, is that what the # hack does?

rules with # will target IE6+7. rules with * will target IE6, but not 7. IE8 seems to have significantly more sane support of CSS in general... not only do the old hacks not work, but most of the time they aren't needed either.

as for the version you post second... the zoom is there to trigger hasLayout engine. inline-block in IE6+7 just triggers hasLayout for inline elements. you can achieve the exact same effect without using inline-block by making it display inline and then triggering hasLayout (like with zoom). that's why the hack works on both inline and block level elements, whereas inline-block in IE6+7 will only work for inline elements.

ah, i see what you mean with that post. what happens there only happens because it's in two separate css blocks. the first block sets it to inline-block, which triggers hasLayout. the second block sets it back to display inline, without un-triggering haslayout because it's done in a separate block. if it was one rule, that would not work. it would instead ignore the inline-block and use the inline statement... never triggering hasLayout.

in short, you can do without the zoom part only if you're using multiple css rules to do it. it our situation, this is not the case. you need the zoom.

Using & in our mixin will allow us to generate two selectors that are the same. I use this trick in the +clearfix mixin. But it seems with any complex selector that would result in more generated css, not less.

chris - use whatever technique you believe to be the most elegant solution. personally... i cheat. i cheat like crazy. i cheat either by using a rails plugin or dojo to add css classes to the html element representing what browser the client claims to be, what os, etc. it lets me avoid css hacks entirely without using conditional comments (which i would not be able to use to target firefox2, for example). it's unfortunate that such a solution is out of the scope of what sass, and compass, could provide. i mean... it makes the selectors themselves more specific, so you could theoretically run into problems. dojo's own inline-block hack is pretty much the same as the one i posted, without the additional firefox2 fix, so as to avoid css specificity issues.

I'm not looking for elegance. Just trying to find a reasonable balance in this effed up world of hacks that we live in. Thank you for your contribution and explanation. I think adding a class to the document body that indicates browser is a nice solution, but not general purpose enough.

I've merged a fix for this into my local edge. It will be part of the v0.10 release.

Fixed in 0.8.13. Just released.

I can confirm this issue is resolved.

You're correct. That line is not needed. That it shows up is a bug.

I've fixed it on edge about a week ago and it will go out with the next release. Thanks for the report.

This was fixed in v0.8.12.

This was recently brought up on the mailing list.

I will add it for the next release. Thanks!

fixed in 0.8.13 -- just released.

That change was introduced as part of the v0.9.1 release of blueprint. Compass is currently at v0.9.0. I would like to update to blueprint v0.9.1 as part of the compass v0.10 release. If you'd like to help with that effort, let me know. I'll file a separate issue for the v0.9.1 upgrade.

This change should be part of the v0.10 release.

016c911
63795c8

too

fixed in v0.10

[Compass Core] The enumerate function now accepts an optional argument to specify the separator. Closed by e0732c8.

Fixed. Please grab the latest versions of compass and the 960 plugin.

Fixed by 772a58d and e744c1e

I also encountered this problem. The fix works but it is also unclear to me why. I believe it might have something to do with the new Dir.glob method in 1.9

Fix a bug in FSSM for ruby 1.9. Closed by bad615e.

Well, I uninstalled haml deleting the haml/init.rb and did the rake rails:template ... command again and this time it installed.
So, just a note for me to remember and might b for someone in future.

I close this issue, it's not a bug.
config option is used to load a file and not create one… I'm stupid >_>

http://gemcutter.org/gems/compass

Wow lovely ! (I had tried chriseppstein-compass)

What version of compass?

Well, I have compass 0.8.17 installed globally, but from the traceback it appears to be using the git checkout I'm in, not the global gem. The checkout is from here http://github.com/ericam/compass/tree/edge (testing Eric's Susy example); based on a checkout of your edge as of this morning.

Eek. the issue is that I'm using a form of Array#index that only exists in ruby 1.8.7+

I pushed a change to my edge branch

I was thinking about this just yesterday - I'll second this motion.

I will talk to nathan about whether this is a sass or compass bug.

If the configuration file changes, wipe out the sass cache and force
compilation. Closed by 3bb5e6d.

Just to be sure: this is not a Sass bug, correct?

Not a sass bug. When the configuration changes, there's no way for Sass to know that the function calls will generate different results. At first, I thought this bug and the one related to line_comments might be related via a root cause in sass, but no.

Interesting. Aren't these the same?

I thought they were the same too until just now. I changed it from 1em to 1 in firebug and saw the computed line-height change from 12px to 24px which is what I had expected. Learn something new every day.

fixed. Thanks for the patch.

fixed. turns out you couldn't effectively set any boolean property to false.

fixed by f1bb236

fixed.

Thanks. I'll get that into the next release.

[Blueprint] Bug Fix: variable referenced in a non-script context within the dquo mixin in the fancy_type module. Closed by 5f32043.

Can you post the relevant bits of the files to a gist and link it here, from this description I can't diagnose the issue.

You got it! http://gist.github.com/247826

I had to move the comment, but once I did that I get the following:

$ compass
   exists stylesheets
  compile src/skin_black.sass
   create stylesheets/skin_black.css

$ compass -v
Compass 0.10.0 [2465bab]
Copyright (c) 2008-2009 Chris Eppstein
Released under the MIT License.

As you can see, it works fine. Perhaps you can tell me more about your environment? Are you using compass stand alone or with another framework?

I'm going to see if I can reproduce it without my crazy huge files.

Chris, I found the problem. For some reason I had a vine.sass and a vine.sass that were identical. They were both importing default.sass so when I saw the error I didn't realize it was being generated from vine.sass. I removed vine.sass and everything is right in the world again.

Sorry to bug you!

glad you got it sorted out.

This has already been fixed in v0.10. you can install it like so:

sudo gem install compass --pre

The logic behind the current order is based on frequency of specification in my experience of common usage and the fact that if you don't specify an argument, no color is specified.

To be honest, I didn't know there was a color order convention, and if I had I probably would have followed that. It's hard to change this without forcing all current users to update their mixin calls when they upgrade.

Can you point me to a reference of some kind that I can use to see this convention?

Lastly, I want to add a feature to Sass that allows property style passing of arguments, then this kind of mixin would really clean up.

Thanks for the quick response, Chris. The ordering is an informal convention which arose back in the day to address minor usability concerns, as well as inconsistencies with IE (surprise!). More information here:

http://meyerweb.com/eric/thoughts/2007/06/11/who-ordered-the-link-states/
http://www.mezzoblue.com/css/cribsheet/ (search for 'vader')
http://archivist.incutio.com/viewlist/css-discuss/40308

You're right that changing the order of the arguments might bork up a lot of existing installations, but it may be worthwhile to modify the order in which they're written to the stylesheet.

(And optional property style calls would, indeed, fix things up nicely -- the extra verbosity could really go a long way toward making calls to obscure mixins more self-explanatory.)

Anyway, I'm a Rails/HAML/SASS/Compass newbie, and I gotta say, I'm really digging Compass. I've been writing HTML (and later CSS) by hand since 1997, and Compass is making the Rails learning curve feel less steep. Great work :)

Love the idea of a maven plugin. thanks for working on that.

fssm is designed to degrade gracefully to polling on unsupported platforms. But I don't see any reason why jruby should not be supported.

If you're in a big hurry, you can probably monkey patch fssm to force it into polling mode for your case while we work out a fix.

And, of course, any help you can offer in finding that fix would be appreciated.

I'm working on a Mac, so I expect it's something related to JRuby not being able to hook into the FSEvents.

As you suggested, I've just hacked it at present to always use polling. Maybe a flag (--forcepolling) would be enough to sort out JRuby support in the short term. Note: I still haven't actually verified that polling works under JRuby, but I assume it will.

With JRuby support sorted, the maven plugin should be fairly straight forward. (There's some messing around with having to automatically install the gems to the local fs, but it's all workable)

Cheers,
Andrew

FYI: I'm tracking the fix for the root cause here:

http://github.com/ttilley/fssm/issues/#issue/2

I thought this might happen. thanks for the platform detection tips, But I think this is more about the terminal than the OS. I need to figure out if there's an ansi capable terminal to do this correctly.

In the meantime, you can turn off the colors by adding color_output = false to your configuration.

Not sure if this helps at all, but I just tested and it does actually work if you require win32console...

http://i.imgur.com/aK05X.png

The only change I can see that might be doing it is this was added to the blueprint reset:

html
font-size: 100.01%

The blueprint changeset was http://github.com/joshuaclayton/blueprint-css/commit/9be685760014b3258dcd83913b9b19f130551b2f

And it doesn't give an exact reason for the change. This is why granular commits are helpful :-P

I have sent an email to the blueprint mailing list to understand this change better.

http://groups.google.com/group/blueprintcss/browse_thread/thread/310c177ec4ec4d83

Patch here:
http://github.com/elliotcm/compass/tree/fix_grid_overlay_bug

Hey Dave,

I don't have a fully setup Win/Rails environment to test this out on, so I may need your debugging help. Can you try following the examples on this site?

http://blog.anlek.com/2009/04/rails-templates/

My best guess would be that we need to override the rake method (as they do) to support win32, this is actually a problem with the Rails templating system :(

Sorry! Let me know how that goes, and maybe push a fix?

I have fixed this and tested it on Vista. I sent Derek a pull request. Should have this solved soon.

Wow. I was actually just going into my e-mail to respond to Derek that I have just forged ahead with plain CSS and would re-evaluate this at a later time, and lo and behold there's a fix! You guys rock!

:) thanks

here is a link to the template, it hasn't gotten merged into master yet

http://github.com/jsilver/compass/blob/0933a1665ecd83f37719f70305a0d896d33d89f7/lib/compass/app_integration/rails/templates/compass-install-rails.rb

save that to a file called compass-install-rails.rb

and then run: rails -m compass-install-rails.rb project_name

thanks
jonathan

Argh. Still doesn't work. :(

I downloaded the patched compass-install-rails.rb file and ran the command as you specified to create a new project to test it out. Below is the session I ran with the error output:

      What CSS Framework do you want to use with Compass? (default: 'blueprint')
960
      Where would you like to keep your sass files within your project? (default: 'app/stylesheets')

      Where would you like Compass to store your compiled css files? (default: 'public/stylesheets/compiled')

     gem  haml
     gem  chriseppstein-compass
    rake  gems:install GEM=haml
    D:/Dev/Languages/ruby/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/core_ext/kernel/agnostics.rb:7:in ``': Exec format error - rake gems:install GEM=haml RAILS_ENV=development

I also still don't have the app/stylesheets directory. I'm not really sure what I'm doing wrong. Any ideas? :(

Thanks for the help.

EDIT Well of course I don't have the stylesheets directory. After looking at the code it never makes it that far, since it is dying on the HAML gem install. The specific error seems to be with how ActiveSupport is implementing the ` method to allow shell execution. I could manually execute each one of these commands, but I tried that last time and seemed to run into problems. Maybe I'll give it another try...

EDIT 2 OK I can install it manually by piecing together the remaining commands from compass-install-rails.rb (i.e. manually running the rake commands, building the compass/init.rb file, etc) and it seems to work just fine. I now have SASS and HAML running and compass seems to be doing its thing. I just can't seem to figure out why it won't run automatically. I'm feeling pretty confident that this is NOT a bug in ActiveSupport, but beyond that I'm stumped... :(

Thought this might help a little until we find out about the template

http://wiki.github.com/chriseppstein/compass/easy-compass-install

Thanks Jonathan, that did work for me. That's essentially what I did yesterday and got a new project up and running, though I went a bit further and manually built the compass command from the compass-install-rails.rb file and also unpacked the gems into the vendor/gems directory. I then repeated the steps into an active project I'm working on and it worked fine.

It was way too late by then to try and learn compass though so I stuck with CSS, but its nice knowing the simple approach so when I come back I can start it up easily and try it again. It looks like a really awesome little framework. Thanks for all the help, and hopefully through this someone else is helped by the easy install info you provided.

Thanks again.
-dave

Actually that whole welcome page is in shambles. I might just remove it unless I have time to make it add serious value.