Disagree. What HTML5 needs is a common set of widgets, usability guidelines, and artwork that make it easy to produce applications that users will enjoy aesthetically and understand how to use implicitly.
The DOM/CSS/JS is a crappy, low-level, do-everything-yourself model for creating applications when compared to the state of the art in native UI/application frameworks. The result is a hodgepodge mishmash of broken, inconsistent application UIs.
Couple that with the inability for any existing browsers' JS runtime to make use of SMP in a single app (despite devices adopting multicore ARM), limited uptake of WebGL, no support for dropping to NEON or even just C (you pay for inefficiency with battery life and poor user experience), etc.
I'd rather see Google produce a NaCL-based set of application libraries that can run on both their Android phones, ChromeOS devices, and our existing desktops. Mozilla's insistence in continuing to invest in pure HTML/JS/CSS is myopic.
The DOM/CSS/JS is a crappy, low-level, do-everything-yourself model for creating applications when compared to the state of the art in native UI/application frameworks.
Well, yes and no. This is a bit like saying that assembly language is a crappy, low-level, do-everything yourself model for creating applications, so that we should not use any language that compiles to assembly language. DOM/CSS/JS are just the brick-and-mortar, there. People are smart enough to build great stuff with them.
Awful stuff, too, of course, but we can just throw it away :)
I think there are at least two problems with using DOM/CSS/JS as building blocks:
1) It discards the network effects/value of having a common, regularly updated platform, shared across all applications.
2) DOM/CSS/JS are terribly inefficient building blocks in terms of processor, memory, graphics. Why waste resources on overly high-level building blocks that we just plan to abstract away.
If those building blocks are going to be abstracted anyway, then maybe we should just skip them. Should we build on top of canvas or WebGL instead?
Apple's accessibility work demonstrates that it is still possible to make native UIs be text-navigable/indexable/structured, which seems to be one of the biggest arguments for keeping the DOM.
Well, your first point is again "let's not use assembly language, it lacks a standard library". Yes, the remark is true, but this just means that we lack higher-level tools above DOM/CSS/JS.
For your second point, I somewhat disagree. JS is now quite efficient. Not CUDA fast yet, sure, but much faster than, say, Python, VB, and often much more memory-efficient than Java. To the point that some video games have been automatically recompiled from C/C++ to JavaScript (through Emscripten) and work quite nicely. Similarly, DOM/CSS are inefficient for really low-level stuff, but suddenly become pretty efficient for animations, for instance.
And, really, the biggest argument for keeping the DOM is not technology, but community: many people know how to use it to do cool stuff.
But yes, canvas + JS or WebGL + JS are also available, for applications that require them.
It's called Twitter Bootstrap. But seriously, there are any number of standard mobile widgets one can use out there from Bootstrap to JQuery Mobile to Sencha touch if all you want is a boilerplate design for app development. I take it you're not a designer, though, because as soon as you want to create applications that don't look like very other app out there you run into the pain of trying to create custom layouts using iOS and Android native development tools. CSS/HTML is far superior, IMO, to the interface tools you get with XCode and the Android Development Tools.
"Any number of" and "standard mobile widgets" makes for an oxymoron.
As for working with designers, no, I'm not a designer, but I find that implementing designs in iOS and Android native tools is far easier than attempting to jimmy HTML+CSS into implementing the behavior and layout as provided by a designer.
In the world of views, I can simply position them where I want and apply arbitrary logic to how they move, scale, etc. This makes it tremendously easier to implement complex designs than straight HTML/CSS.
This looks very interesting, but if I'm reading the w3c proposal correctly, I think the CSS/HTML divide still makes it extremely cumbersome; is there any way for an x-tag to accept an argument that modifies its drawing via CSS?
The DOM/CSS/JS is a crappy, low-level, do-everything-yourself model for creating applications when compared to the state of the art in native UI/application frameworks. The result is a hodgepodge mishmash of broken, inconsistent application UIs.
Couple that with the inability for any existing browsers' JS runtime to make use of SMP in a single app (despite devices adopting multicore ARM), limited uptake of WebGL, no support for dropping to NEON or even just C (you pay for inefficiency with battery life and poor user experience), etc.
I'd rather see Google produce a NaCL-based set of application libraries that can run on both their Android phones, ChromeOS devices, and our existing desktops. Mozilla's insistence in continuing to invest in pure HTML/JS/CSS is myopic.