It would be nice if jekyll allowed the use of Less for stylesheet processing. I've written up code to do such at: http://github.com/nirvdrum/jekyll/tree/integrate_less
The shoulda tests and Cucumber features should make clear what's going on. The gist of it is that a file named "whatever.less" in the "_stylesheets" directory will get transformed to "_site/css/whatever.css". It support arbitrary nesting of subdirs in the "_stylesheets" directory to support CSS hierarchy organization.
I'm open to suggestions on the "_stylesheets" and "_site/css" naming convention.
Another thing to note is that if there is a "css" directory at the root level, the contents will be merged during transformation. As such, I've left the "css" directory in tact in the test sources. The screen.css file could just as easily be moved into the "_stylesheets" directory, where it will not be processed, as it does not have the ".less" extension.
I don't understand why the _stylesheets directory is necessary. Why not just run LESS over any file with a .less extension, just as Textile is run over .textile files and Markdown on .md/mkdwn/markdown files?
Maybe I'm missing the point, but it seems to me we should continue to use the convention of letting the file extension dictate the filter used in the Convertible module, and skip all the _stylesheets directory logic. My same argument should hold true for SASS and HAML as well.
The _stylesheets directory is a parallel to the _posts directory. As far as I know, jekyll only runs textile and markdown over files in the _posts directory (I haven't actually tried anywhere else). LESS will only be be run over files with a .less extension, so SASS files should be able to be placed in _stylesheets without any problems.
I suppose the alternative is to allow them to be placed anywhere and then not publish the .less files.
Okay, I understand your thinking now, but actually Jekyll runs Markdown or Textile over any file with the corresponding extension, not just posts. This is done in the Convertible module that is included and called from the Page and Post modules.
An example of this would be my about.textile page on my site:
Gotcha. That's a feature I haven't used. So, I'm not opposed to the proposed change. It'll require some reworking of the patch though.
I've implemented Less integration in my fork in a dumb way (see it here around line 200). This follows the simple rule of the extensions dictating the filter. Would this, in principle, be a suitable solution? (this is not a pull request, but an implementation suggestion)
I was playing around with something similar. It seems like the change could better be made in two phases:
With the plugin support now, supporting less becomes trivial. Here's a gist that will accomplish transforming all .less files (containing the YAML front matter) into the corresponding css: https://gist.github.com/668957. Place it in your _plugins folder
You could also always just use less.js: https://github.com/cloudhead/less.js
Yes. I think the recent plugin support makes this possible. This ticket can probably be closed.
I have a gist that compiles files via less.js, although it's broken in >= 0.9.0 (see issue #268)
Maybe I misunderstand, but isn't the point of less.js that it doesn't need the compiler? From my tests you just need to add the following two lines to your template:
<link rel="stylesheet/less" href="/stylesheets/main.less" type="text/css" />
Your gist seems to add support for less, which is also great and can be done via the plugin system.
Yep -- my gist is a Jekyll plugin.
You're right -- you can use less.js in the browser during development without precompilation, but for decent performance, you'll want to compose Less into standard CSS on a production site. Personally, I find Jekyll + this plugin (which uses node.js to compile) to be faster and easier to debug, even during development.
You can add Less preprocessing capability via the Jekyll Asset Pipeline plugin. Might be worth checking out.
Yep, check the plugins or pipeline gems out.