Initially, I set off to write quite a big post about how I want my version of HTML to be, offering more simplicity and capability by having a few tags included in the already existing version.
Then I realized, there is no need to write an elongated post, it is possible to succinctly present what I want in HTML in a few words. What I really want in HTML is a simple method of communicating between the server and the client without refreshing the page (like they do in Ajax style programming). In my view, the current mechanism of behind the scene request/update is not simple and elegant enough to make sense of the overall process with better readability.
To achieve it, we would only need three simple attribute tags for an HTML element (such as a dropdown list box), postbehindscenetrigger, postbehindscenedata and postbehindsceneresponsehandler and this is how the three attributes can be laid out inside an HTML element tag:
<select id="dropdown1", onchange="onchangeDropdown1Trigger",
postbehindscenetrigger="onchangeDropdown1Trigger",
postbehindscenedata="getdataOnchangeDropdown1"
postbehindsceneresponsehandler="handleOnchangeDropDown1Response"......>
The basic idea is whenever the JavaScript function onchangeDropDown1Trigger is triggered (due to any operation on the client side), a server side function will be invoked and the server side function's argument would be a stream of data which would be obtained from the client side JavaScript function getdataOnchangeDropdown1. The server's address can be taken from the form where the HTML element (in this case, a dropdown combo box) resides. To keep things simple, a nice convention for the server side event handler can be formname_postbehindscenetriggername(string data). In this case, the server side event handler function name can be form1_onchangeDropdown1Trigger(string data).
And postbehindsceneresponsehandler is a simple client side JavaScript function with a string argument as first parameter which gets triggered automatically when the server responds to the client request for onchangeDropDown1Trigger.
Although the example is for a dropdown, we should able to use any HTML GUI element to have features to perform Ajax style server-client communication behind the scene (and if required, without the knowledge of the user).
The above mentioned concept is a basic idea to keep dynamic Ajax based web programming simple and elegant. We can tweak the argument of the above mentioned three functions as well as the server side function to come up with more classy and elegant solution. Moreover, some basic argument parsing functions can be introduced in the JavaScript libraries to put the argument string fragments (separated by certain delimeters) in proper variables in an orderly fashion to make the whole process even simpler. An example can be the implode method of PHP, how it nicely places the variables contained in a string in an array - I am referring to the possibility of such functions in the JavaScript libraries for argument parsing in similar fashion; but instead of an array, it may put the arguments (contained in one long string) in a map. Using of proper framework will help to achieve this Ajax style data communication by just a few clicks as well. If this paragraph is not making any sense, don't bother; you'd know what I am wanting to tell if you ever get a chance to implement my chain of thoughts regarding client server communication with my version of HTML in your programming.
Have I gone wrong somewhere here? Too simple a solution for the web gurus yet to implement? I don't know. I don't know also, why it took almost a decade to get a basic and necessary tag like IFrame to be integrated in (and compatible among) all browsers.
None the less, the ultimate objective of this post is the standardization of behind the scene client server communication, so that when you switch from programmer to programmer, you don't have to see different codes to achieve the same purpose... (for example, on change of a combo box, populate a field somewhere in the document). If you use the three functions that I mentioned, you would see a standard practice which would be easy to follow as a code reviewer.
Before coming up with negative suggestions against this idea, I hope some thoughts would be given in favor of it.
Signing off,
Mukit
