I've never heard of HAML before. From the website, is it literally just "markup should be beautiful"?

I mean, LESS/SASS add real functionality. Even CoffeeScript adds functionality to JavaScript, beyond just changing the syntax. But is there any functional advantage to use HAML? Is it actually worth half a chapter of an "advanced guide to HTML & CSS"?

(Totally my opinion, but it doesn't even look clearer or "more beautiful" to me, but maybe that's just because I'm used to HTML.)

Oh, come on. You got hung up on an adjective used in a hero unit.

http://haml.info/docs/yardoc/file.REFERENCE.html

Filters, passing Ruby objects into it to generate classes, hell, even markup comments that don't show up in html.

I was a little surprised to see so much dedicated to HAML in an HTML/CSS tutorial. The author's background is as an instructor at the starter league which is heavy on Rails. HAML is widely used in that community so his perspective might be slightly bias.

But it is still useful to know and see there are other ways to handle to write HTML.

And that is because it is more than "markup should be beautiful". I cringe when that is stated as the only reason. Markup that is simplified can lead to easier readability and fewer mistakes. It removes the worry if you forgot to close a tag and removes them all together.

I was hesitant at first after being so used to working with HTML but I am happy as ever after making the switch. I find my time is more productive and updating the html is much quicker.

I've used HAML for 4 years now, my take on it is that HAML gets the computer to do work it can dependably do (writing out closing tags) and reducing substantially how much I have to type. Less typing means less code to maintain but also easier to see the purpose of the code.

I love this series.

Can anyone give an example of when HAML would be used in the 'real world'? I can't imagine it filling a niche that isn't covered by any of the other templating languages: what would seem most ideal is a combination of say, Jinja and HAML.

I'm finding that it's a lot cleaner to use with Javascript. For example, say you have an array of items and you want to create a fieldset for each item, and add an attribute of "data-id", and "data-category" to each fieldset so you can grab them with jQuery later on.

In HAML all you have to do is this...

- @items.each do |item|

  %fieldset{:data => {:id => item.id, :category => item.category}}

===

In ERB the equivalent would be...

<% @items.each do |item| %>

  <fieldset data-id="<%= item.id %>" data-category="<%= item.category %>">

  </fieldset>

<% end %>

===

It's a lot cleaner in HAML, especially extrapolated out over larger views.

Look into `tag`: http://api.rubyonrails.org/classes/ActionView/Helpers/TagHel...

ERB view:

    <%= render @items %>

items/_item.html.erb:

    <%= tag "fieldset", data: { id: item.id, category: item.category } %>

My old company used HAML exclusively for all of our RoR view code. In most general cases it makes the coding faster. THere are of course some wonky edge cases in HAML vs code style best practices.

For instance: try making an html element with a long list of attributes and see how it looks. Or worse, run a translate on a block of text while maintaining reasonable line lengths.

Good? Yes. Silver bullet html replacement? Lol.

I've always done html elements with long attribute lists, simply multiline:

    <div attr1="val1, the first one"
         attr2="val2, maybe this one is much longer"
         attr3="you see where I'm going with this"
         attr4="and so on...."
    >
        Div content goes here
    </div>

What do you mean by "run a translate" though?

I know a lot of ruby on rails developers who use HAML for their template framework instead of ERB. Some people prefer HAML's use of indentation instead of using tags to enclose everything.

I like it in my projects mostly for how clean and easy it is to read. It takes a little bit to get used to initially but it is worth it.

...and you can combine it with Sass for CSS. Sass gives you features that CSS misses like inheritence which makes your style sheets much more DRY.

BTW, both Haml and Sass go very nicely with Sinatra... ;)

SASS also works for ERB. They are independent but I do agree that they are great together.

Is there some SASS integration in HAML beyond regular HTML?

You might be interested in shpaml-jinja[0]. It extends the shpaml[1] syntax to provide jinja commands.

[0]: https://github.com/p/shpaml-jinja [1]: http://shpaml.webfactional.com/examples

Quick nitpick: HAML is not a pre-processor for HTML, it is a templating language.

Anything that is self-described as an "abstraction markup language" and must be compiled into the language it abstracts is really a pre-processor.

Regardless of intended use cases, i cant think of a better definition.

I disagree. A preprocessor doesn't 1) transform the entire document 2) doesn't fully parse the input document that is exactly why the c family on languages has such difficulty with modules: they are hacked on with a preprocessor and aren't part of the language.