Designing proper HTML code

I think there is a need to engineer HTML code in a web web application, the same way server side and client side code is engineered. I'm posing my self the question how?
For standard programming languages I use UML, but UML can't be applied to HTML. Html denotes the structure of a hyper text it doesn't model interactions or functions. It can't be effectively described with standard software engineering techniques.
HTML code is simple, and short and anybody can learn to do it in one hour. It would seem to the causal user that HTML doesn't need to be specially engineered. I think that is not the case. Every web application is always finally rendered into HTML. All user interactions are defined by how the page is structured in HTML, the way the server side code is structured depends on the way HTML is structured and the ease CSS can be developed also depends on the way HTML is structured. Not to mention cross browser and cross platform portability.
It really matters if a developer uses tables withing tables, or a series of stacked divs. It really meters the decision between table cells and unsorted lists or paragraphs. When put in perspective, most problems I've encountered in my career as a web developer had to do in a way with badly engineered HTML.
I think it is critical to find a way to design and plan markup code for web applications. If we as engineers spend so many hours a day preparing or code and our applications to be of the maximum quality, I think it is imperative to spend the same energy on HTML.
I know what you think. HTML is not serious, it is for kids not engineers. But look around you. Web applications are everywhere, and so it is HTML. Without HTML there would not be the world wide web as we know it. Its simplicity is what it drove web applications inside and outside the corporate firewalls. And neglect to properly engineer HTML code is one of the root causes of the poor qualty many web applications suffer.
It just came to me today, this idea. I spent several days designing several objects in UML, documenting them, writing them, testing them, writing and thinking about unit test, automating them, and it all worked as a charm. But when it got down to HTML and its sister cousin CSS I worked as newb coding like hell without preparing out a head, doing a crap job on a critical part of the application I'm working on. I can't put it there like that. I have to rewrite it tomorrow to increase the quality of the code I'm producing. But how many hours of work would I saved if I engineered my HTML code in the same way I engineered my javascript and C# code?

Learning the devils way : killing the interest first

I grow tired of the endless stream of SQL going into my head on daily bases. It all looks the same, but with subtle differences. I'm just no so interested to learn what different flavors of create table exist out there. But I must. But I so needed to advance my self career wise.
So I soldier on. Learning T-SQL every day, one hour a day. My personal learning time. And during my project time I'm learning PL/SQL. Of course my project time doesn't allow me much time to learn all that I need about the damned Oracle SQL dialect, so I learn during my break, during my free time at home in the evenings experimenting on the Oracle 10g EX database I've installed on my Ubuntu machine for just that purpose.
But it tires me so. I would rather learn Jquery or Dojo, or read some new PHP book (like PHP in Action from Manning), or continue my studies of Django or learn a new cool language like Erlang or OCaml. But not. I'm stuck with T-SQL and PL/SQL. It is my choice. One that I had to make.