The <canvas> tag is underpowered compared to native 2D APIs, and trying to render anything using CSS is a mess. Way too complex.
Canvas is a pretty low level API. What is underpowered about it ? Is it underpowered because it only exposes primitives ? You can take those primitives and build anything on top of them, again, Canvas is like using straight Xlib or Quartz 2D to draw out a rich UI with dialogs, buttons, scrolling views, etc.. You have to write the whole code, that is the purpose of the API, being low level. Rich libraries will be built on top of Canvas exposing all of that as higher-level CreateDialog() type functions that do all of this work for you eventually. It's in its enfancy.
Or is the fact you find that the implementations (not the specification, let's not mix them up) are slow because they use software rendering ? Don't forget that that is an implementation limitation, not a limitation of the API/specification. Nothing is stopping browser vendors from shipping accelerated Canvas implementations.
You keep saying "sucks, underpowered" yet you justify nothing. You have no argument really beyond the usual flaming.
Lack of classes, compilation, and static typing?
Classes : Javascript is a procedural language at heart, like C, like Perl, like Pascal. However, like C, like Perl, some people have grafted OO concepts on it. You can create "classes" in Javascript, you have a this pointer (like self in Obj-C), you have constructors, inheritance and polymorphism.
Compilation : How does compilation make a language not suck ? Again, you ignore the fact that most browsers implement JIT compilation, making Javascript essentially the same as Java and .NET that also use this same JIT compilation in their respective VM and CLR environnements. What gets executed is the same native code.
Why is the intermediate compilation step to Bytecode something you value ? What inherent lack of suckage does Bytecode provide over straight source ? Faster compilation times ? Do we even notice on Core 2 Duos ?
Static Typing : Some people would say this is an advantage, not a con

You happen to like static typing (I do to), some people don't. A lot of "native development languages" don't have static typing.
Again, I recognize that HTML 5 is a significant improvement over earlier versions. However, it does not compare to what you can do with a native toolkit such as Cocoa, Android, or WPF.
Again, you fail to qualify what it is you're trying to do. I doubt "Classes, compilation and static typing" are things programmers set out to do. They are features of the languages we use to implement stuff. What is it you want to implement that lacks a proper API in the proposed HTML5 set of APIs/specifications ?