Haml Blog

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:

dd35eda28a98d70d75f4a0c07cdb20f6920e5a2d

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!

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.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.