Why do standards like WebSockets don't include anything that can be used in pure HTML? This would be a great tool for building efficient dynamic apps, if you could "submit" forms without going to a new page, and then get incremental page updates as a response.
I'm not sure I see the use-case there as being more useful than JS based WebSockets. Writing a general JS library to do what you suggest would be pretty straightforward, and the server-side work wouldn't be any different (serving partial HTML based on request type).
If your users are worried about security / performance enough to turn off JavaScript, they probably wouldn't want "HTMLSockets" enabled, either.
If your users are browsing with a browser so old it doesn't have a reasonable JavaScript engine, then it wouldn't support "HTMLSockets," either.
Basically, there's nothing you could do with "HTMLSockets" that you can't do with WebSockets, and with only a small layer to make it so. However, there's a whole host of utility that you get from WebSockets that you could never get from HTMLSockets, or would require a huge amount of hacking in order to get it to work.
And all this is beside the "pureness" argument, where one might say that HTML is for data, CSS is for design, JavaScript is for behavior; WebSockets are behavior, not data.
This is like asking why we should bother having any (new?) HTML or CSS standards at all, when you could write a custom rendering engine in JavaScript for every website.
There is tremendous value in having a solid, usable foundation for web development that doesn't rely on an imperative language to work. To start with, declarative features are semantic and allow for semantic upgrades on wide-scale basis. Do you like your Firefox/Chrome spell-checking in text areas? Do you like them being resizable? Well, this wouldn't be possible if all textareas were some JavaScript hack. (Hey, with only small layer you could actually fake a textarea. Does that seem like a good idea in retrospect, though?)
Also, it would be great to be able to develop simple dynamic web applications (or prototypes) without doing something complex. Progressive enhancement is buried far too early.
If your users are worried about security / performance enough to turn off JavaScript, they probably wouldn't want "HTMLSockets" enabled, either.
I frequently browse with JavaScript blocked by default, and I can tell you right here that this assumption is invalid. There is a world of difference between JavaScript library and a standard, declarative technology. The latter is more likely to be faster, have less bugs, no side-effects and be secure.
And, how does one get sufficiently customisable incremental updates without having to standardise (and implement) a huge complex new language to control them?
What's so bad about having a declarative way of doing something that a lot of people will find useful?
And, how does one get sufficiently customisable incremental updates without having to standardise (and implement) a huge complex new language to control them?
By using element IDs. Every element in the incoming frame that has and ID that matches and ID of an existing element replaces it in the document. People have been doing this for years. It's called AHAH (Asychronous HTML and HTTP). Doing this without any custom code and with every update being as cheap as sending WebSockets frame would be absolutely awesome. It could be used to create very sophisticated and dynamic applications with very little complexity either on the client or on the server side.
