Issues - chriseppstein/compass

chriseppstein / compass

1285

Description:

Compass is a Stylesheet Authoring Environment that makes your website design simpler to implement and easier to maintain.

Sort by: Priority | Votes | Last Updated

Loading…

14.

3 votes

feature
x

Submit gem to rubyforge
5 comments Created 5 months ago by cheba

Title

Body
I found a project on rubyforge but no gems on there. Why not submit gem there?
or cancel

I found a project on rubyforge but no gems on there. Why not submit gem there?

Comments

chriseppstein Mon Jun 08 12:54:59 -0700 2009 | link

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.

Comment
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.
or cancel

adamsalter Wed Oct 14 21:42:05 -0700 2009 | link

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 ;)

Comment
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` ;)
or cancel

Mange Thu Oct 15 00:51:56 -0700 2009 | link

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.

Comment
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.
or cancel

chriseppstein Thu Oct 15 07:04:57 -0700 2009 | link

The compass gem is already on gemcutter:

http://gemcutter.org/gems/compass

This is where I'll posting new releases.

Comment
The compass gem is already on gemcutter: http://gemcutter.org/gems/compass This is where I'll posting new releases.
or cancel

Mange Thu Oct 15 07:58:33 -0700 2009 | link

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.

Comment
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.
or cancel

Parsed with GitHub Flavored Markdown
29.

0 votes

blueprint
x

bug
x

Blueprint form alignments
5 comments Created 4 months ago by chriseppstein

Title

Body
The fields of blueprint forms are not the same within compass as they are in blueprint.
or cancel

The fields of blueprint forms are not the same within compass as they are in blueprint.

Comments

mrship Fri Jul 10 03:05:27 -0700 2009 | link

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

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

chriseppstein Sat Jul 11 14:06:23 -0700 2009 | link

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

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

enricob Sun Aug 30 14:55:47 -0700 2009 | link

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. =(

Comment
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. =(
or cancel

wakiki Sun Nov 08 09:47:05 -0800 2009 | link

Is there any update to this?

Comment
Is there any update to this?
or cancel

enricob Mon Nov 09 06:32:59 -0800 2009 | link

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

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

Parsed with GitHub Flavored Markdown
40.

0 votes

bug
x

compass core
x

feature
x

Bug: Found IE bug with inline-block mixin
11 comments Created 2 months ago by joshjhall

Title

Body
Appended the last line to the current inline-block mixin to fix IE6 / IE7 display. Seems to be working fine for me, but might require additional testing. =inline-block :zoom 1 :display inline :display -moz-inline-box :display inline-block :vertical-align top :*display inline
or cancel
Appended the last line to the current inline-block mixin to fix IE6 / IE7 display. Seems to be working fine for me, but might require additional testing.
```
=inline-block
  :zoom 1
  :display inline
  :display -moz-inline-box
  :display inline-block
  :vertical-align top
  :*display inline
```
Comments
chriseppstein Sun Aug 16 16:46:13 -0700 2009 | link

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.

Comment
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.
or cancel
ttilley Mon Aug 17 04:36:23 -0700 2009 | link
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
Comment
please test my fix that was [posted to the newsgroup](http://groups.google.com/group/compass-users/browse_thread/thread/5837fbc002575b75/a6f5c023c682345f?lnk=raot#a6f5c023c682345f). =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
or cancel
chriseppstein Mon Aug 17 07:47:41 -0700 2009 | link
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?
Comment
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?
or cancel
chriseppstein Mon Aug 17 07:53:00 -0700 2009 | link

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

Comment
I found [this post](http://www.webmasterworld.com/css/3649638.htm) on the subject. They use conditional comments to target IE < 8, is that what the # hack does?
or cancel

ttilley Mon Aug 17 08:01:30 -0700 2009 | link

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.

Comment
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.
or cancel

ttilley Mon Aug 17 08:09:01 -0700 2009 | link

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.

Comment
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.
or cancel

ttilley Mon Aug 17 08:09:48 -0700 2009 | link

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.

Comment
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.
or cancel

chriseppstein Mon Aug 17 08:11:50 -0700 2009 | link

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.

Comment
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.
or cancel

ttilley Mon Aug 17 08:20:13 -0700 2009 | link

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.

Comment
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.
or cancel

chriseppstein Mon Aug 17 08:44:35 -0700 2009 | link

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.

Comment
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.
or cancel

chriseppstein Thu Aug 27 13:32:30 -0700 2009 | link

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

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

Parsed with GitHub Flavored Markdown
45.

1 vote

blueprint
x

feature
x

Upgrade Blueprint to v0.9.1
1 comment Created 2 months ago by chriseppstein

Title

Body
Blueprint version 0.9.1 was recently released with the following changes: 9be68576 Fixing bugs, see Lighthouse for changes 414d9242 Add visibility:hidden to hr.space so it's useful outside of white backgrounds. 7cdabb82 Added PSD template to help with mockups c2493689 css_parser now uses Array#join instead of Array#to_s for ruby1.9 compat 74d7ecf9 Change CSS append order to put custom CSS after plugin CSS--allowing custom CSS to over-ride plug-in properties. 4d61d5db Changed custom CSS comment to file name instead of file path--removing the need to sanatize the CSS comment for security/privacy reasons. b881bf59 Fixed some typos in TUTORIAL.textile. e9e91bb9 When splitting on a colon for key/value CSS pairs, use first colon as the only split Signed-off-by: Joshua Clayton <jclayton@fusionary.com> eb58cdef Fix grid builder to properly generate png 0811b3d6 Allow for the specification of a non-default settings file via the command line in compress.rb d77e914e Password inputs got the same style as regular text inputs. 0f7588a5 Cleaned up whitespace in changelog; updated version numbers within stylesheets 05312a80 Updating authors one last time 2dd0d5ed Updating contributors, fixing grid.css 7e63ed3e Cleaning forms.html 3bf83f71 Test form whitespace cleanup bdd4568f Remove p tag Compass needs to merge these changesets into it's port.
or cancel
Blueprint version 0.9.1 was recently released with the following changes:
```
9be68576 Fixing bugs, see Lighthouse for changes
414d9242 Add visibility:hidden to hr.space so it's useful outside of white backgrounds.
7cdabb82 Added PSD template to help with mockups
c2493689 css_parser now uses Array#join instead of Array#to_s for ruby1.9 compat
74d7ecf9 Change CSS append order to put custom CSS after plugin CSS--allowing custom CSS to over-ride plug-in properties.
4d61d5db Changed custom CSS comment to file name instead of file path--removing the need to sanatize the CSS comment for security/privacy reasons.
b881bf59 Fixed some typos in TUTORIAL.textile.
e9e91bb9 When splitting on a colon for key/value CSS pairs, use first colon as the only split Signed-off-by: Joshua Clayton <jclayton@fusionary.com>
eb58cdef Fix grid builder to properly generate png
0811b3d6 Allow for the specification of a non-default settings file via the command line in compress.rb
d77e914e Password inputs got the same style as regular text inputs.
0f7588a5 Cleaned up whitespace in changelog; updated version numbers within stylesheets
05312a80 Updating authors one last time
2dd0d5ed Updating contributors, fixing grid.css
7e63ed3e Cleaning forms.html
3bf83f71 Test form whitespace cleanup
bdd4568f Remove p tag
```
Compass needs to merge these changesets into it's port.
Comments

chriseppstein Tue Sep 08 17:52:11 -0700 2009 | link

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

Comment
This change should be part of the v0.10 release.
or cancel

Parsed with GitHub Flavored Markdown
47.

0 votes

Use CSS-style properties instead of the old Sass-style properties
0 comments Created about 1 month ago by chriseppstein

Title

Body
We need to convert the compass sass code to use properties with colons that come at the end instead of the beginning of the property name.
or cancel

We need to convert the compass sass code to use properties with colons that come at the end instead of the beginning of the property name.

Comments

Parsed with GitHub Flavored Markdown
48.

2 votes

watch not working in ruby 1.9.1
1 comment Created about 1 month ago by btomlin

Title

Body
I keep getting an error when running the watch script on ruby 1.9.1. I'm using version 0.8.17 >>> Compass is watching for changes. Press Ctrl-C to Stop. TypeError on line ["969"] of /System/Library/Frameworks/Ruby.framework/Versions/1.9.1/lib/ruby/1.9.1/pathname.rb: can't convert Pathname into String Run with --trace to see the full backtrace I have traced it to the following: Basically what's failing is Pathname.glob(Pathname.new('/Users/bryan/Sites/ushaf/public/src/\*\*/\*.sass')) (fails in irb as well) The pathname is passed in, I just used Pathname.new to test but Pathname.new('/Users/bryan/Sites/ushaf/public/src/\*\*/\*.sass').to_s works fine. If I change vendor/fssm/state.rb from def add_glob(base, glob) Pathname.glob(base.join(glob)).each do |fn| @cache.set(fn) end end to: def add_glob(base, glob) Pathname.glob(base.join(glob).to_s).each do |fn| @cache.set(fn) end end There is no longer a problem, but I'm not sure why. the trace... /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/1.9.1/pathname.rb:969:in `glob' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/vendor/fssm/state.rb:49:in `add_glob' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/vendor/fssm/state.rb:45:in `block in snapshot' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/vendor/fssm/state.rb:45:in `each' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/vendor/fssm/state.rb:45:in `snapshot' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/vendor/fssm/state.rb:37:in `recache' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/vendor/fssm/state.rb:9:in `refresh' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/vendor/fssm/backends/polling.rb:10:in `add_path' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/vendor/fssm/monitor.rb:18:in `path' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/compass/commands/watch_project.rb:26:in `block (2 levels) in perform' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/compass/commands/watch_project.rb:25:in `each' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/compass/commands/watch_project.rb:25:in `block in perform' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/vendor/fssm.rb:19:in `call' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/vendor/fssm.rb:19:in `monitor' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/compass/commands/watch_project.rb:24:in `perform' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/compass/commands/base.rb:15:in `execute' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/compass/commands/project_base.rb:19:in `execute' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/compass/exec.rb:242:in `do_command' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/compass/exec.rb:57:in `perform!' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/compass/exec.rb:40:in `run!' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/bin/compass:8:in `<top (required)>' /usr/local/ruby/bin/compass:19:in `load' /usr/local/ruby/bin/compass:19:in `<main>'
or cancel
I keep getting an error when running the watch script on ruby 1.9.1.

I'm using version 0.8.17

Compass is watching for changes. Press Ctrl-C to Stop. TypeError on line ["969"] of /System/Library/Frameworks/Ruby.framework/Versions/1.9.1/lib/ruby/1.9.1/pathname.rb: can't convert Pathname into String
Run with --trace to see the full backtrace

I have traced it to the following:

Basically what's failing is
Pathname.glob(Pathname.new('/Users/bryan/Sites/ushaf/public/src/**/*.sass'))

(fails in irb as well) The pathname is passed in, I just used Pathname.new to test

but Pathname.new('/Users/bryan/Sites/ushaf/public/src/**/*.sass').to_s works fine.

If I change vendor/fssm/state.rb from
```
def add_glob(base, glob)
  Pathname.glob(base.join(glob)).each do |fn|
    @cache.set(fn)
  end
end
```
to:
```
def add_glob(base, glob)
  Pathname.glob(base.join(glob).to_s).each do |fn|
    @cache.set(fn)
  end
end
```
There is no longer a problem, but I'm not sure why.

the trace...

/System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/1.9.1/pathname.rb:969:in glob' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/vendor/fssm/state.rb:49:inadd_glob' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/vendor/fssm/state.rb:45:in block in snapshot' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/vendor/fssm/state.rb:45:ineach' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/vendor/fssm/state.rb:45:in snapshot' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/vendor/fssm/state.rb:37:inrecache' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/vendor/fssm/state.rb:9:in refresh' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/vendor/fssm/backends/polling.rb:10:inadd_path' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/vendor/fssm/monitor.rb:18:in path' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/compass/commands/watch_project.rb:26:inblock (2 levels) in perform' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/compass/commands/watch_project.rb:25:in each' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/compass/commands/watch_project.rb:25:inblock in perform' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/vendor/fssm.rb:19:in call' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/vendor/fssm.rb:19:inmonitor' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/compass/commands/watch_project.rb:24:in perform' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/compass/commands/base.rb:15:inexecute' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/compass/commands/project_base.rb:19:in execute' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/compass/exec.rb:242:indo_command' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/compass/exec.rb:57:in perform!' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/lib/compass/exec.rb:40:inrun!' /System/Library/Frameworks/Ruby.framework/Versions/1.9/lib/ruby/gems/1.9.1/gems/chriseppstein-compass-0.8.16/bin/compass:8:in <top (required)>' /usr/local/ruby/bin/compass:19:inload' /usr/local/ruby/bin/compass:19:in `'
Comments

haarts Sun Nov 01 09:22:54 -0800 2009 | link

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

Comment
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
or cancel

Parsed with GitHub Flavored Markdown
49.

0 votes

rake rails:template installation halts
1 comment Created about 1 month ago by wnn

Title

Body
I wanted to give it a shot and ran with the rails template using: rails <myrailsappnamehere> -m http://compass-style.org/rails/installer and did worked successfully. Now I am installing in my existing project which is already hamlified. So I ran the following rake command: rake rails:template LOCATION=http://compass-style.org/rails/installer and now the execution halts and does nothing as the following <pre> [~/rails_apps/myapp (design)⚡] ➔ rake rails:template LOCATION=http://compass-style.org/rails/installer (in /home/millisami/rails_apps/myapp) applying template: http://compass-style.org/rails/installer =================================================== Welcome to the Compass Installer for Ruby on Rails! =================================================== 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 rake gems:install GEM=chriseppstein-compass rake gems:unpack GEM=chriseppstein-compass gem chriseppstein-compass-960-plugin rake gems:install GEM=chriseppstein-compass-960-plugin rake gems:unpack GEM=chriseppstein-compass-960-plugin file vendor/plugins/compass/init.rb executing haml --rails . from /home/millisami/rails_apps/myapp </pre> I tried couple of time and its the same. Is it due to my already hamlified app?
or cancel
I wanted to give it a shot and ran with the rails template using:
rails -m http://compass-style.org/rails/installer

and did worked successfully.
Now I am installing in my existing project which is already hamlified.
So I ran the following rake command:
rake rails:template LOCATION=http://compass-style.org/rails/installer

and now the execution halts and does nothing as the following
```
[~/rails_apps/myapp (design)⚡] ➔ rake rails:template LOCATION=http://compass-style.org/rails/installer
(in /home/millisami/rails_apps/myapp)
    applying  template: http://compass-style.org/rails/installer
===================================================
Welcome to the Compass Installer for Ruby on Rails!
===================================================

              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
        rake  gems:install GEM=chriseppstein-compass
        rake  gems:unpack GEM=chriseppstein-compass
         gem  chriseppstein-compass-960-plugin
        rake  gems:install GEM=chriseppstein-compass-960-plugin
        rake  gems:unpack GEM=chriseppstein-compass-960-plugin
        file  vendor/plugins/compass/init.rb
   executing  haml --rails . from /home/millisami/rails_apps/myapp
```
I tried couple of time and its the same. Is it due to my already hamlified app?
Comments

wnn Sat Oct 10 12:14:45 -0700 2009 | link

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.

Comment
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.
or cancel

Parsed with GitHub Flavored Markdown
50.

0 votes

Link order? (LVHFA)
2 comments Created 29 days ago by reidman

Title

Body
Would it be possible to make a minor change to the +link-colors mixin so that it accepts link colors in the 'usual' order, which is LVHFA (link, visited, hover, focus, active)? Not sure if there was a specific reason for the existing order (LHAVF). Thanks!
or cancel

Would it be possible to make a minor change to the +link-colors mixin so that it accepts link colors in the 'usual' order, which is LVHFA (link, visited, hover, focus, active)? Not sure if there was a specific reason for the existing order (LHAVF).

Thanks!

Comments

chriseppstein Mon Oct 12 12:16:56 -0700 2009 | link

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.

Comment
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.
or cancel

reidman Mon Oct 12 13:10:34 -0700 2009 | link

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 :)

Comment
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 :)
or cancel

Parsed with GitHub Flavored Markdown
51.

0 votes

Compilation failed with the --config option
1 comment Created 26 days ago by piouPiouM

Title

Body
Stack trace: $ compass --config=src/sass.rb --trace my_project NameError on line 68 of /Library/Ruby/Gems/1.8/gems/chriseppstein-compass-0.8.17/lib/compass/commands/project_base.rb: undefined local variable or method `file' for #<Compass::Commands::CreateProject:0x5a3c00> /Library/Ruby/Gems/1.8/gems/chriseppstein-compass-0.8.17/lib/compass/commands/project_base.rb:52:in `read_project_configuration' /Library/Ruby/Gems/1.8/gems/chriseppstein-compass-0.8.17/lib/compass/commands/installer_command.rb:9:in `configure!' /Library/Ruby/Gems/1.8/gems/chriseppstein-compass-0.8.17/lib/compass/commands/project_base.rb:18:in `execute' /Library/Ruby/Gems/1.8/gems/chriseppstein-compass-0.8.17/lib/compass/exec.rb:242:in `do_command' /Library/Ruby/Gems/1.8/gems/chriseppstein-compass-0.8.17/lib/compass/exec.rb:57:in `perform!' /Library/Ruby/Gems/1.8/gems/chriseppstein-compass-0.8.17/lib/compass/exec.rb:40:in `run!' /Library/Ruby/Gems/1.8/gems/chriseppstein-compass-0.8.17/bin/compass:8 /usr/bin/compass:19:in `load' /usr/bin/compass:19
or cancel
Stack trace:
```
$ compass --config=src/sass.rb --trace my_project
NameError on line 68 of /Library/Ruby/Gems/1.8/gems/chriseppstein-compass-0.8.17/lib/compass/commands/project_base.rb: undefined local variable or method `file' for #<Compass::Commands::CreateProject:0x5a3c00>
  /Library/Ruby/Gems/1.8/gems/chriseppstein-compass-0.8.17/lib/compass/commands/project_base.rb:52:in `read_project_configuration'
  /Library/Ruby/Gems/1.8/gems/chriseppstein-compass-0.8.17/lib/compass/commands/installer_command.rb:9:in `configure!'
  /Library/Ruby/Gems/1.8/gems/chriseppstein-compass-0.8.17/lib/compass/commands/project_base.rb:18:in `execute'
  /Library/Ruby/Gems/1.8/gems/chriseppstein-compass-0.8.17/lib/compass/exec.rb:242:in `do_command'
  /Library/Ruby/Gems/1.8/gems/chriseppstein-compass-0.8.17/lib/compass/exec.rb:57:in `perform!'
  /Library/Ruby/Gems/1.8/gems/chriseppstein-compass-0.8.17/lib/compass/exec.rb:40:in `run!'
  /Library/Ruby/Gems/1.8/gems/chriseppstein-compass-0.8.17/bin/compass:8
  /usr/bin/compass:19:in `load'
  /usr/bin/compass:19
```
Comments

piouPiouM Fri Oct 16 07:15:47 -0700 2009 | link

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

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

Parsed with GitHub Flavored Markdown