Should HTML be split into two protocols?

by Gene Michael Stover

created Sunday, 2013-01-27 T 20:02:33Z
updated Sunday, 2013-02-03 T 17:33:18Z

We use web browsers & HTML to two types of presentations to users:

  1. as document markup (hypertext) &
  2. as client-side of client/server applications.

As document markup (hypertext)

When I'm reading an online essay or book, I'm thankful when it's just text with readable formatting & useful links. A Wikipedia page is an example of this. I'm upset when an essay or book has gratuitous animations, drop-down lists that popup if my cursor moves over an arbitrary word, or doesn't allow me to be sure I've read all of the work.

As client-side of client/server applications

We also have web sites that are clearly applications. Some are done very well. Examples include Gmail, Hotmail, & Netflix. They are okay when done correctly though sorely annoying when done poorly.

Where I get upset is when something that should be the first group that is implemented as an application.

Do we need two protocols?

The two types of web sites make me wonder if instead of using HTML for both hypertext & applications, the world would benefit from two protocols: Should we reserve HTML for hypertext documents and create a separate language to describe client-side applications to web browsers?

New media

Is it possible that there's a new way of presenting material that requires both the hypertext & application capabilities of HTML, one that doesn't fit into my list of two (or three?) categories?

Yes, there is such a possibility. In fact, I'm certain that more imaginative people will create some inarguably new & advantageous way to present information that is neither the hypertext we have nor application but something else. But no one has done that yet. So far, we're still working on slight variations on old concepts, & I stand behind my two (or three) categories.