nex3 / haml

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.

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.

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 should behave just like the :javascript filter, except with <style> tags instead of <script> tags.

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.

Having the ability to output variable values in comments are a needed informative tool.

Example:

=font-size-pixels-to-ems( !pixels )
  !ems = !pixels / 16
  font-size = !ems+em
  /*
    16 x !ems = !pixels

p
  +font-size-pixels-to-ems(18)

Should print out:

p {
  font-size: 1.125em;
  /* 16 x 1.125 = 18 */ }

However, it is currently printing out:

p {
  font-size: 1.125em;
  /* 16 x !ems = !pixels */ }

When outputting normal html with haml, it shouldn't wrap javascript in CDATA.

Haml/Sass 2.2.14 (Powerful Penny)
Rails 2.3.5

There are a number of functions that can be succinctly expressed in SassScript. Can we provide a way in Sass for defining functions using SassScript in Sass files instead of in ruby?

@function px-to-em($pxval, $baseline = 12px)
  $pxval / $baseline * 1em

Then this could be used just like a ruby-defined function:

div
  font-size= px-to-em(18px)

Mixins should be allowed to include themselves. A good example for this is when you are creating a theming environment in your CSS.

For example, lets say you have theme1 and theme2.

The folder directory would look like

theme1/
  pages/
    1.sass
    2.sass
    3.sass

theme2/
  pages/

If the pages for theme 2 were very similar to theme1 then there is no point in copying in branching the sass files from theme1 and putting them in theme2 (now you are forced to maintain 2 different versions). Instead, this approach is prefered (assume we are trying to override page 1 for theme2.

theme1/pages/1.sass :

=page-1-css
  color: red
  font-family: Arial

Now theme 2 has an option, it can redefine +page-1-css or choose to extend or overwrite it.

Extending it would look like:

@import ../theme1/1.css
=page-1-css
  +page-1-css
  font-family: Arial

Overwriting it would look like:

=page-1-css
  display: block

Now, depending on your theme, you import all pages for that theme, and one page's CSS could extend another theme's page. So you reduce the amount of SASS you have to maintain.

The problem is that mixins will not allow you to include itself currently.

=test-mixin
  color: red

=test-mixin
  +test-mixin
  font-weight: bold

div
  +test-mixin
  font-family: Arial

returns this error:

stack level too deep

Stick multibyte characters anywhere in the haml layout file and rails crashes with

   invalid byte sequence in US-ASCII

To replicate this, add %p== अंशुल anywhere in application.html.haml

ruby 1.9.1
rails 2.3.5
haml 2.2.17

I just reported this on bundler http://github.com/carlhuda/bundler/issues/issue/44 they in turn said its a haml gemspec issue.

The fix seems rather easy, just do not source any files from the gemspec.