The direct translation of that HTML to Haml is

    %button#Save.positive(name='Save' type='submit' tabindex='10')
      %img(src='/graphics/icons/save.png')
      Save Changes

That button in your example, of course, has a lot of attributes, more than most elements in a typical template. Also, if you are using it with Rails it'd be in a form block with a helper:

    = f.submit 'Save Changes', :class => 'positive'

which would generate an <input> that you'd then style with CSS (or Sass :-D)

Note that with Haml you can also write any sort of helpers you want, so you could have something as simple as

    = button

doing whatever you want it to.

Where it gets really interesting, however, is when you are dealing with full templates. The document structure is instantly apparent, most superfluous noise is gone, classes and ids are given top billing and templates are very short despite retaining all of the information.

> The document structure is instantly apparent, most superfluous noise is gone

Except that normally document structure is already apparent. Most people don't write HTML pages from top to bottom -- sites consist of a common header, footer, sidebars, etc. Common controls (such as buttons, date selectors, voting tools, etc) can hide most of the superfluous noise. What then remains is easy to follow. It seems like Haml is to HTML what assembler is to machine language -- it's merely a 1-to-1 translator. Which is great if you want to work at that level but it seems you could get more bang for your buck with a higher level tool.

The big disadvantage of Haml is that it isn't HTML. Now using any template engine takes you away from HTML, but hopefully you get some real value added. With Haml, it's the same structure with a better markup. I don't see what the big deal is.

You can do it this way:

    .button#save{positive, style(:save), etc}

Where "positive", "style", and "etc" are functions returning Hash. I don't bother, and put most of that stuff in jQ.