HTML should not be used for UI, it's for inserting content and from elements into a presentation. CSS, with the help of graphics and javascript for interactivity should do the UI.
Then in a CSS page referenced by that presentation, you do whatever you want to #site-menu; you make it a vertical menu, horizontal, tabbed, or even generate big fat fish-eye icons that look like the Mac's. HTML knows nothing of that.
Used in this sense, HTML is a very good object code.
In a world where you can layer truly higher-level UI elements on top of them? Just because some elements map 1:1 doesn't mean all do. You can generate a button from <button /> or <input type="submit" /> but that goesn't mean you can't generate image "buttons". The final generation of a "button" should be left to your rendering module.
This is very similar to addition being a far higher level process than the ADD opcode present in every instruction set. Sure, sometimes addition translates to a single ADD, but not always.
What you're describing is what most would call "skinning" or "theming", whereas "user interface" is generally considered to penetrate much deeper into the functionality of the app. Decoupling UI requires an incredibly abstract description of functionality. I've never seen a practical and generalizable example of such a thing.
Skinning, as you point out, often demands modification to the DOM, a task to which HTML and CSS alone are unsuited. It can be done with JavaScript, but it's much more practical and reliable to use a server-side abstraction a la ASP.NET or Seaside. This is more or less the point made by the original article.
Doing something like:
Should generate this: Then in a CSS page referenced by that presentation, you do whatever you want to #site-menu; you make it a vertical menu, horizontal, tabbed, or even generate big fat fish-eye icons that look like the Mac's. HTML knows nothing of that.Used in this sense, HTML is a very good object code.