Run rip install git://github.com/nex3/haml.git.

Now, try and require Haml. It fails as the Version class tries to look for the VERSION file in the root directory of the Haml package. Uh oh. Rip doesn't keep anything around other than the lib directory of the gem so there is no VERSION file.

See chriseppstein/compass-colors. Only the Sass extensions (and corresponding HSL code) should be integrated - the color themes should be left there.

Most of the work for this will probably be in testing and documentation. The compass-colors tests aren't as complete as I'd like... it would be good to have tests for each of the new Sass functions. And the new functions should be documented in the YARD style of the rest of the Sass functions.

Allow multiple filters to be composed in Haml - first apply the rightmost one, then work your way left. For example,

:preserve:escaped
  <foo>
    <bar />
  </foo>

should produce

<foo>
  <bar />
</foo>

This filter should be the same as :plain, except that it should interpret #{} within it as literal text, not interpolation. For example,

:no_interpolation
  foo #{bar} baz

should compile to

foo #{bar} baz

Currently, Haml insists that all indentation in a file be completely consistent. However, this means that it's not possible to get rid of a line without re-indenting everything beneath it, which is annoying when debugging code.

We want to allow variable indentation as long as it's unambiguous. For example, the following:

%foo
  %bar
      %baz
        bang
      boom

should be the same as

%foo
  %bar
    %baz
      bang
    boom

However, wherever we currently would raise an error, a warning should be printed.

Ambiguous cases should still be marked as erroneous. For example, the following

%foo
    up four spaces
  down two spaces

should raise an error on the "down two spaces" line.

This is conceptually the same as issue #29, but since Sass and Haml don't share parser code, they're listed separately.

Currently, Sass insists that all indentation in a file be completely consistent. However, this means that it's not possible to get rid of a line without re-indenting everything beneath it, which is annoying when debugging code.

We want to allow variable indentation as long as it's unambiguous. For example, the following:

foo
  bar
      baz
        bang: bop
      boom: bip

should be the same as

foo
  bar
    baz
      bang: bop
    boom: bip

However, wherever we currently would raise an error, a warning should be printed.

Ambiguous cases should still be marked as erroneous. For example, the following

foo
    up: four spaces
  down: two spaces

should raise an error on the "down: two spaces" line.

This is conceptually the same as issue #28, but since Sass and Haml don't share parser code, they're listed separately.

Colors printed by SassScript when the output format is :compressed should be printed in the smallest possible format. This means the shortest of "#nnnnnn", "#nnn", and the HTML4 color name, depending on what's available.

When running with :ugly => true and :format => :html4 or :format => :html5, don't put quotes around attributes that don't require them. See the HTML4 spec for a precise definition of when they're not required.

When running with :ugly => true and :format => :html4 or :format => :html5, don't output closing tags that aren't required. A list of closing tags that aren't required is given here. Note that sometimes these closing tags should be printed. In particular, if the closing tag isn't followed immediately by an opening or tag - one generated by Haml - output it. For example, in all of the following situations:

%p foo
<strong>bar</strong>
%p foo
= "<strong>bar</strong>"
%p foo
:plain
  <strong>bar</strong> 

the closing tag should be preserved.

Warning: it's likely to be very difficult to figure out exactly when you may and may not output a closing tag.

currently only double quotes will highlight as a string, single quotes are just as valid and should be highlighted also.

This is probably an issue in all sorts of Sass frameworks... we might want to make the solution more general-purpose.

This should behave just like the :javascript filter, except with <style> tags instead of <script> tags.

For example,

=box-shadow(!value)
  -moz-box-shadow= !value
  -webkit-box-shadow= !value

+box-shadow(0 1px 3px rgba(0, 0, 0, 0.5))

should list both line 2 and line 5 in the backtrace. This should integrate with the existing import backtrace.

At the beginning of the file, // encoding: name should have an effect as close as possible to that of Ruby's # encoding: name declarations.

Note that this is currently not applicable to Haml because Haml templates are usually loaded externally to Haml. See #38.

Raising an issue to open discussion. I don't know either Haml or Mustache codebase well enough to start work on this straight away.

Chris Wanstrath (aka defunkt) has just released a great template engine 'Mustache' based on Google's CTemplate.

As a templating solution Mustache is great, but I don't think anybody can deny the cleanness and readability of HAML code.

I don't think it would be too difficult to modify HAML to support Mustache-like generation. This could even be an option on HAML which could be turned on an off.

I'm thinking something like:

a) no ruby code evalution, so (-, =) no longer evaluate.

b) new syntax {{#boolean}}, {{helper}}, {{{non_interpreted_helper}}} can be used anywhere in the code(ie as nodes and inside text nodes) and will be evaluated as expected.

c) integration into rails could be very simple. All template logic now goes into the helpers files.