Haml 4.0 has been released!

It’s finally here! I’m happy to announce that Haml 4.0 has been released to Rubygems and is ready for you to install right now.

This release includes many improvements, including SCSS, Less and Coffeescript filters; better HTML5 support; hyphenated data attributes; security, performance, and thread-safety fixes; and much, much more

Now, I hate to sound like the fine print on a package of aspirin, but you must know that some of the changes in Haml 4.0 might break your application. Haml no longer supports Rails versions earlier than 3.0, nor does it support Ruby less than 1.8.7. The Sass filter now always outputs a <style> tag. Data attributes are now hyphenated, not underscored. The html2haml utility has been moved to the html2haml gem. The Textile and Maruku filters moved to the haml-contrib gem.

If you’re worried about breakage, please pin Haml to the 3.1 series using “~> 3.1” in your Gemfile or other gem version management code of your choice until you’ve had the chance to update. Haml 3.1 will be maintained for bug fixes indefinitely for those users who can’t or don’t want to upgrade to Haml 4.0.

The 4.0.0 gem’s SHA1 is:


On a brief personal note, I’d like to take a moment to thank a few of the many people who contributed to this release:

Nathan Weizenbaum for maintaining Haml for many years, contributing to the earliest work on this release, and trusting me as the new maintainer.

Matt Wildig for coming on board as committer and fearlessly tackling most of the hardest problems.

Nick Walsh for his beautiful redesign of the Haml website.

Hampton Catlin for creating Haml and always being available to provide feedback, support and encouragement.

Now, get out there, try out the new version and let us know what you think!

What’s new in Haml 3.2 beta?

It’s been a while since I’ve posted anything, but a lot has been happening behind the scenes. First of all, my second son, Oliver, was born 5 weeks ago, so I’ve had a whole lot more than Haml on my mind lately!

Luckily for the project, though, Matt Wildig has come on as a core committer and been picking up my slack for the last few months. The upcoming 3.2 release includes tons of great work by him. We’re close to ready to release 3.2.0, but are going to do another beta or two, and then a few release candidates to make sure we catch as many bugs as possible.

So what’s new in Haml 3.2? I’m glad you asked. This will be an incremental release without any major language changes. Our overall goals for 3.2 have been to fix bugs, simplify the codebase, improve the default settings, and remove annoyances.

So with that said, here are some of the highlights coming your way in the next release:

Improved Filters

Filters are now based on Tilt, making it much easier to add new ones. If it works with Tilt, it works with Haml. As such, we’ve also added a few new filters for more popular things like LESS, Coffeescipt and The SCSS flavor of Sass.

The Sass and other CSS-oriented filters now automatically wrap your code in <style> tags too. That means if you rely on the :sass filter in any of your apps, you’ll have to adjust some of your code when updating to Haml 3.2.


We’ve made several changes to Haml’s defaults to make its output more in line with what people expect in 2012. HTML5 is now the default output format everywhere. It already was the default in Rails, but if you’re using Haml with Sinatra, Padrino or Ruby frameworks, this may affect you.

Haml also now uses dashes when building HTML5 data attributes from hashes - previously it used underscores, which many users found surprising and/or annoying.

Security Fixes

The Erb filter now uses the same XSS-safety features as the rest of Rails.


Haml now supports only Rails 3.0+ and Ruby 1.8.7+. This change allowed us to eliminate a significant amount of code. The Haml 3.1 branch will continue to be maintained for bug fixes for people running older Rails apps that can’t update to Haml 3.2.

The `html2haml` utility has been extracted to its own gem.

We’ve added a haml-contrib gem to have a place to put less-frequently used features, and moved the Textile and Maruku filters there.


Haml’s test suite now emits only one warning, down from several thousand that 3.1.5’s test suite emitted. Haml is also now tested green against JRuby and Rubinius on Travis.

We removed lots of dead code and refactored in a few places to make the code easier to understand and maintain. In particular, we split out the parser and compiler modules into separate classes; previously they had been mixed into an engine module and couldn’t be used on their own. Programmers looking to hack on Haml’s compiler and parser will have an easier time on 3.2.


Haml’s parser got some modest performance improvements and is now a little less than 10% faster than Haml 3.1’s. This has little effect on production applications, since in production templates are generally only parsed once and then cached. Still, every little bit helps. 

We also fixed a major performance issue when rendering lots of partials on JRuby.

Miscellaneous Things

We’ve added a few other minor features and configuration options, and fixed lots of small bugs. If you’d like to see all the details check out the changelog.

Summing up…

Haml 3.2 has more of what you love and less of what you hate. It will improve your life in numerous ways: you’ll be more attractive, more wealthy and become smarter if you use it. Well, not really, but we think there’s something in this release to make almost everybody just a little happier with Haml. Give it a try and send us your feedback!

Haml 3.1.6 is released!

I’ve just pushed 3.1.6. to Rubygems - since there were no problems reported, it’s identical to 3.1.6.rc.1 from a few days earlier. As always, if you experience any problems please report them on our issue tracker.

Haml 3.1.6.rc.1 released

Recently I released 3.1.5 to work around a change in Rails 3.2.3 which made textarea helpers append newlines to the opening tag. Rails’s motivation for this change was to fix a longstanding bug which impeded the ability to save texarea content with leading newlines.

Unfortunately, Haml 3.1.4 treated this newline as content, rather than as a seperator between the textarea tag and its content.

Solving the issue was not simply a matter of decoding the newline, because in indented mode, Haml would add spaces before the newline in partials, making nested textareas have spaces before their content.

Haml 3.1.5 solved this by adding <haml:newline/> rather than a newline, and monkeypatched Rails to replace it with a real newline after the document was rendered. You ever do something you just *know* is going to cause problems, even though all your tests seem to indicate things are working fine? Yeah, I know that feeling.

As it turns out, monkeypatching how Rails does the actual rendering is not as easy as it seems. First, because there are several places where a monkey patch needs to be applied. Second, because those modules are not always loaded, and it’s not very nice to force people to load them in order to use Haml: an application may have a very good reason not to have loaded part of Rails.

Last but not least, the monkeypatch caused <haml:newline/> to appear in some Erb documents when the Haml gem was loaded for use elsewhere in the applcation.

Haml 3.1.6 attempts a simpler and wiser solution to the issue. Rather than adding some silly tag (WTF was I thinking???), Haml now replaces the first encoded newline emitted by Rails’s textarea helper methods with a real newline. Then, when rending the Haml document in ugly mode, everything works exactly as you would expect, with no need to monkepatch Rails’s template rendering.

However this comes with a tradeoff: in order to not completely break textareas in indented mode, Haml will now make no attempt to reindent a partials or the output of helpers when they match a very simple regular expression for opening <textarea>, <pre>, or <code> tags.

This makes textareas work properly in Haml 3.1.6. at the expense of slightly uglier documents, when those documents contain the listed tags.

Now, everybody knows that you shouldn’t rely on regular expressions to parse HTML. This is where another tradeoff comes in: parsing the buffer with an XML parser would have a much larger impact on performance, and Haml is already slow enough as it stands in indented mode. So I’ve compromised and used a simple, somewhat braindead, but fast regexp.

This issue has been nagging and annoying, and I apologize to anybody affected by this, most especially for the <haml:newline/> silliness in introduced in 3.1.5. Please give Haml 3.1.6 a try (it’s currently in the stable branch) and on Rubygems and let me know if you come across any problems. I’ll try to get this release out as soon as possible.

To install via Rubygems, simply do: gem install haml -v 3.1.6.rc.1 —pre

Or, add it to your Gemfile: gem “haml”, “3.1.6.rc.1”

The change is also in the master branch, for those who like to live dangerously.

Haml 3.1.5 released!

Haml 3.1.5 has just been released. This release includes fixes to better support Rails’s html_safe flag and Rails 3.2.3’s textarea helpers. Since there were no issues reported, Haml 3.1.5 is exactly the same as Haml 3.1.5.beta.1 and Haml 3.1.5.rc.1.

If you come across any issues with this release, please report them on our issue tracker. Happy hamling!

Haml 3.1.5.rc.1 released

I’ve gotten no bug reports indicating problems with Haml 3.1.5.beta.1, so I’ve released it unmodified as 3.1.5.rc.1. If no problems appear, then this will be released unmodified as Haml 3.1.5 on Monday, May 7th.

Haml 3.1.5.beta.1 released

I’m just catching up and posting this on the blog, but Haml 3.1.5.beta.1 has been released.

This release fixes a much-discussed incompatibility with Haml and Rails 3.2.3. The latest release of Rails fixes a longstanding bug with textarea helpers by introducing a newline after the opening tag. Unfortunately, this fix caused problems with Haml 3.1.4 because it treats the newline after the opening tag as part of the textarea content, which means that you could potentially have an extra newline and/or spaces added to your data on each save.

If you’ve been affected by this bug, please give the beta a try. You can install it via Rubygems by executing:

gem install haml -v 3.1.5.beta.1 —pre

or you can add it your Gemfile with

gem “haml”, “3.1.5.beta.1”

If you have any difficulties, please let us know on the issue tracker.

An infrequently updated blog with news and information about the Haml template language.

Blog Archive

Haml Home

Source Code

Google Group