I guess I set myself up? You make some good points about why HTML is a pain in the ass. I'm just desensitized to it to the point that it doesn't bother me anymore. In fact, I didn't even think of the issues you brought up.
What it took for me was writing a UI in Haml with very minimal, semantic markup and all the controls keyed in jQ off classes and IDs.
When you structure your HTML, CSS, and Javascript correctly, Haml is absolutely gorgeous. You're no longer writing in HTML: you're writing in a DSL designed to express user interface. For instance, a "save" button encoded in a DIV in Haml:
.button#save
.foo> This has no whitespace outside the foo div.
.foo< This has no whitespace just inside the foo div.
.foo>< This has no whitespace outside or inside.
I guess I fail to see how html has any advantage over haml. The absolute worst case is that you're still writing html in 90+% of the cases (which you'd be doing anyway without haml), and in the best case, your markup becomes much more DRY and readable.
Some designers I've worked with are ok with haml, others steadfastly refuse because their workflow is so HTML-centric.
<button id="Save" name="Save" type="submit" class="positive" tabindex="10">
<img src="/graphics/icons/save.png">Save Changes
</button>
<ctl:SaveButton />
%button#Save.positive(name='Save' type='submit' tabindex='10')
%img(src='/graphics/icons/save.png')
Save Changes
= f.submit 'Save Changes', :class => 'positive'
Note that with Haml you can also write any sort of helpers you want, so you could have something as simple as
= button
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.
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.
.button#save{positive, style(:save), etc}