Closed paulirish closed 13 years ago
Love it.
+1 to Loving it :)
+1000 using sass since a year for all my django projects, can't think of writing vanilla css any more.
full ack. <3
replacing the php compressor with sass/compass? me like..
the suggestion is not to switch over to sass but to only use it for the build script.
Honestly, as long as sass gets introduced I think it's a step towards a native sass/haml boilerplate.
yes please! even just for @import inling - I'm using the boilerplate with Nicole Sullivan's OOCSS methodology which involves using over 15 stylesheets from a vanilla install (using all the supplied table/tab etc styling plugins of course)
It's a good idea. As I said earlier except @import, inlining and css minification it can generate css sprites. And instead of ruby we can use jRuby, because we already have Java dependency
Were using a similar approach for compass/sass for our current project @work. jRuby works fine, we installed and configured sass/compass to work by only checkin out a jruby installation from our svn.
Developers don´t need to know anything about ruby to work with it. Even with the new compass beta (we used lemonade before), we´re getting easy sprite map generation for free. jRuby + Sass + Compass + Boilerplate = Killer Combo
Were using a similar approach for compass/sass for our current project @work. jRuby works fine, we installed and configured sass/compass to work by only checkin out a jruby installation from our svn.
Developers don´t need to know anything about ruby to work with it. Even with the new compass beta (we used lemonade before), we´re getting easy sprite map generation for free. jRuby + Sass + Compass + Boilerplate = Killer Combo
These are some interesting combos (-: So far I have only attempted integrating OOCSS and Sass but I will give jRuby and Compass a try
I'm using compass/sass in my current project alongside h5bp and I don't think it's a good idea. It's to much dependent of ruby/gems and it's not a very stable and quality project yet. They will get there, but not yet.
I'm using it for 10+ production sites since more than a year and it is awesome. Can you elaborate on your claim of being a not stable and quality project?
This is where java rocks! We can add sass/compass with jruby, cssprefixer with jython, uglifyjs&coffeescript with rhino… and have a huge ass deps folder, yo
Compass does have a lot of dependencies though (all for perfectly valid reasons). Sass, on the other hand, does not have that many.
In my previous comment I was in a hurry and did not explain myself. I was a bit harsh also. I don't like Sass for many reasons but I was wrong to say that sass is not stable or quality code. Sorry for that.
I looked into the project I am using it and found out that most of the problems I was having was with compass and not sass. Their biult-in mixins for CSS3 have a lot of problems. We ended replacing most of the mixins for manual code from manual generators like border-image-generator and Ultimate Gradient Generator.
Concerning Sass, I was happy to find out a post that explain almost all of my concerns: Lea Verou: On CSS preprocessors. In addition to what the article says, I think that nesting CSS rules is also problematic if not used with care. Even using compass just for the build process and CSS minification in not a good choice, since including any CSS preprocessor as a dependency could encourage people to use it and this could lead to badly optimized CSS output. This is just the opposite of what H5BP is trying to accomplish with the build process.
Apart from that, in this topic there is few comments regarding the advantages of compass/sass over the current build process. What is the great advantage? Is it so great for H5BP to drop the Java only philosophy? Including jRuby does not change the fact that people looking to customize the build process would have to develop and debug in ruby. Having a "huge ass deps folder", as mentioned, is not a thing that I would like to have in any of my projects for no reason.
@Irae you're assuming that anyone new to compass/sass will write messy css?
imho, the build process is not trying to accomplish or enforce anything. for me, it's just an optimization tool. you can easily write bad codes with or without compass/sass.
but i have to agree by adding compass/sass we add more dependencies. just had an experience a few weeks a go helping one of my interns to install ruby + compass/sass in her windows notebook. somehow installation doesn't really go very smooth.
I'm just saying that these rare case can discourage someone from using H5BP.
we already have a compass extension for html5 boilerplate desktop and mobile. anyone already using compass/sass in their workflow should use these tools instead.
@rizkysyazuli an CSS optimization tool has a purpose of outputting optimized CSS code, for me this means smaller and more performant. My opinion is that compass/sass has too many tools that can do exactly the opposite in a way that is hidden from the developers.
closing this as its a dupe of #516 (rake build script) at this point
and oh did i mention we have @import inlining now? CUZ WE DO.
:D
they can do @import inlining and css minification, which we want.
currently they'd replace a php script.
so we'd be trading a php dependency for a ruby/sass/compass one. (but only for the build script). (and technically only for css minification)
but a pro is that we'd bet scss for free.
like it, hate it?