I've noticed that over the past couple years, the most controversial HTML
element proposals have almost always fallen into this category. Consequently,
many are put off by HTML's weak interface (compared to Hypercard or multimedia
authoring tools), and weak document description (compared to any word
processor). I believe this is because HTML is being asked to do everything, and
consequently can't do any of it very well.
So here goes my wild proposal. Perhaps we should define a new language, ala
Tk, which is specifically designed for defining interfaces. There is nothing
that locks HTTP with HTML; two major languages could be handled easily. For
purposes of this argument, I'll call it WIDL (Web Interface Description
Language). It could probably be largely lifted from Tk or other very-high-
level languages. Basically it would be a very compact "program" that would
direct the browser to create new interface elements, carving up the HTML
document space, or open new windows.
This is not the same as sending scripts. These interfaces wouldn't actually
"do" anything. They would create widgets that would either execute standard
browser features (i.e. Back, Home, generate imagemap query, display HTML text)
or execute a URL with one of the defined methods. Thus it would be very
closely tied to the Web, just like HTML is.
With this language, the following things could be shunted off HTML into WIDL:
Forms
Graphical Home Pages
Interactive Graphics
Ralph's suggestion could be handled by a WIDL script that included elements
at the top, and a slightly smaller HTML-page widget.
An advantage of splitting these features off is that they would simplify the
document-description part of HTML, giving it room to add new features in the
field where it belongs without becoming completely unwieldy.
I know this sounds similar to the modular client idea, but the problem with
that approach is that you can never rely on everyone to have all the
necessary modules, and of course you can't send binary modules over HTTP, since
they are large and platform-specific. Also, these could be interpreted well
by non-graphical clients (Lynx).
I hope this doesn't sound like one of those newbie "I want everything" requests,
but I think it can work. I and my geography colleagues have a stack of
applications that are waiting for something like this.
Brandon Plewe
plewe@acsu.buffalo.edu