XAML approach

Before you argue that this is difficult I should point out that this is possible in other "markup" languages like XAML. In this case instead of viewing the markup language as semantic in the narrow non-programmatic sense we consider it to be integral to the programming language.

In fact XAML is an object instantiation and initialisation language. When you use a tag in XAML it is a shorthand for create an object of the same name and when you use an attribute in XAML this initialises a property of the same name. That is, the markup language is deeply integrated with the programming language.

DOM integration

Now consider HTML's integration with Javascript, i.e. the DOM - Document Object Model. When you use an HTML tag it creates an object in the DOM and initialises it. Javascript can then work with the DOM to change the objects so created.

But notice that this isn't full integration - DOM objects are not Javascript objects. Also notice that you can't create a new HTML tag and expect it to instantiate and initialize a new Javascript object of the same name.

Why not?

To treat Javascript or any programming language embedded in the browser as supplying objects that the HTML instantiates and initialises would be simpler and much, much more powerful.

Browser graphics

Of course to make it possible to create new UI controls you would also need access to the browser graphics system. No not Canvas but a top level "root" Canvas that every other graphics entity was created in. With this facility you could draw anything you wanted to on the same basis as the built-in controls - which would of course correspond to Javascript objects.

In this new architecture you could create new HTML controls on an equal footing with what used to be thought of as "standard" HTML controls.

Let's get a VM

Next we come to the language of choice. Why is it we are stuck with Javascript as the only real client-side language we can use?

The main reason is that instead of implementing a virtual machine, language browsers implement an interpreted Javascript. If you want a new language then you need a new language engine. 

A much more sensible way of doing things is to give browsers a built-in VM - Java VM or even the .NET CLR or perhaps something new, given we tend to reinvent the wheel to avoid taking sides. Then Javascript could be compiled to the intermediate language and run as before but then so could any other language of your choice.

Suddenly language support just becomes a matter of having a compiler that targets the correct VM.

Of course you could just take Javascript as the intermediate language and write compilers that target it - this is what Google Web Toolkit does in compiling Java to Javascript. GWT would be a lot easier to create and a lot more powerful if HTML was a general-purpose object instantiation and initialization language.

A new view

None of these ideas would effect the way that HTML/CSS is currently used.

Designers could ignore the fact that it was anything but a mark-up language - as designers do with XAML say. They could apply styles using CSS ignorant of the fact that it was backed by a language subsystem.

Of course all of this misses the point that at the end of the say we don't want to be working with raw HTML/CSS anyway. Picking over the syntax of HTML is like having to work with assembly language in a text editor. Yes some like to do it and regard it as the only true way to program - but it isn't productive.

What we really need is an integrated development environment complete with modern facilities such as interactive debugging, drag-and-drop layout, single stepping, breakpoints, unit tests, auto-documentation, source code management and so on.

Such environments would be much easier to create with a stronger integration between HTML and language facilities.

All you have to do is see web app development as being no different from any other sort of development and demand the same facilities and you quickly realise how feeble a step HTML5 is and how far we are away from anything sensible.

There are lots of other ways in which the browser environment could be improved to make programming easier and more powerful - we just have to put HTML into its proper place and make the programming the top of the stack.

I hate to be a Marvin but yes - HTML5 - I've seen it. It's rubbish.