Concerns about HTML+ complexity
fox@pt0204.pto.ford.com (Ken Fox)
Errors-To: listmaster@www0.cern.ch
Date: Wed, 15 Jun 1994 19:54:41 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <9406151740.AA16962@pt0204.pto.ford.com>
Errors-To: listmaster@www0.cern.ch
Reply-To: fox@pt0204.pto.ford.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: fox@pt0204.pto.ford.com (Ken Fox)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Concerns about HTML+ complexity
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: text
Content-Type: text
X-Mailer: ELM [version 2.4 PL23]
X-Mailer: ELM [version 2.4 PL23]
I just joined this mailing list so I hope that this post is appropriate here.
I'm also assuming that everyone on the other www-* lists reads this list. If
this is not generally the case, could somebody tell me?
</pre>
<p> After reading Dave Raggett's brief paper on HTML+ (which triggered a
brief phone conversation with him) and some of the procedings from the WWW
conference, I've become concerned about the future of HTML. Definitely not
its popularity, but its complexity. This article is a brief summary of my
concerns. I would really like to know how many people share my concerns ---
please, send me mail or post a reply. I'll post a summary if necessary.
<h1>Concerns with HTML+</h1>
<p> These are just some of my thoughts that I feel I need to discuss with
the Web community before the current HTML+/2/3/etc. proposals become so
popular that they can't be changed. My goal here is just to stimulate
discussion and ideas for different ways of pursuing multi-media world-wide
hypertext.
<p> Some of my concerns are technically HTML+ independent, but I'm going to
pick on HTML+ anyway. I think HTML+ will influence the architecture of the
next generation Web browsers, and therefore control what becomes popular in
documents.
<p> One last comment before I get into my concerns: I don't mean to start a
holy war. Hopefully, we will pick the best solution; maybe that's HTML+ as
it stands today, I don't know. Whatever it is, it's vital that we *not*
fragment the Web community so that some people publish for browser A which
uses HTML 2 and and others for browser B which uses HTML 4 --- each of which
are only marginally compatible with each other.
<h2>HTML+ is too large and complex</h2>
<p> One of the great things about HTML is its small size. This means that
browsers can be created easily (well, almost :-) and that new users have
virtually no trouble learning how to create documents. I guess we really
can't add functionality to HTML without sacrificing some of the ease-of-use
in creating HTML documents. That's not true of browser creation though! I
really think we should keep the ability to easily build new browsers. The
area is just too interesting and immature to raise the entry stakes just yet.
It will be a sad day when it takes several people working several months
just to get a basic browser --- how can we expect to see radical new
browsing and navigation aids?
<p> We really need to think about who in the industry is in the best
position to implement/control monolithic standards and monolithic browsers.
It isn't CERN, NCSA or the community of Web hackers, that's for sure! The
only people in a position to implement a monolithic browser are those with
dedicated (and large) programming staffs --- such as Framemaker or Microsoft.
<h2>HTML+ can never do it all</h2>
<p> I can understand where the current philosophy of "put it all in HTML"
comes from. NCSA has followed this policy and it's worked out well for
Mosaic's popularity. I think it's vital that capabilities such as inline
images, sounds, and fill-in forms be available in Web browsers. But who
actually thinks that a Web browser should be expected to do it all? Wasn't
the purpose of HTML to add hypertext *markup* to information? Why then is
HTML+ completely dominated with content representation and presentation
concerns?
<h2>HTML+ is hard to experiment with</h2>
<p> When a browser creator wants to experiment with new rendering features,
tables for instance, it's going to be difficult to isolate the table code so
that it can be easily changed and tested. If a user wants to experiment
with different table rendering it's almost impossible. She has to get the
source code for the browser, figure out the layout algorithms, find where
the table code is, extract it, and then start modifying it. I think this is
unreasonable. Of course this is not HTML's fault directly --- it's one of
the implementation side effects from HTML+.
<h1>Suggestions for improving HTML+</h1>
<p> These are just thought starters. I like them, but they need a lot more
detail. Both technical (which I'm working on) and political (which is why
I'm writing this article.)
<h2>Separate navigation and structure from content and presentation</h2>
<p> I think that HTML should be radically simplified. It should concentrate
on navigation (i.e. hypertext references) and structure (e.g. this table
appears next to this paragraph.) The content (e.g. the text of the
paragraph and the data in the table) and the presentation (e.g. the font of
the paragraph and the column widths in the table) should be called out
either as separate standards or clearly marked sections of HTML+.
<p> I favor separate standards. We could then debate and approve each
standard separately. This way we don't have bits and pieces of HTML+ being
implemented or not implemented as people argue about bits and pieces of
HTML+. The different level of implementation table I've seen (from the WWW
conference procedings) looks like a nightmare. Anybody with any experience
in IGES (a U.S. graphics exchange standard used primarily in the CAD
industry) can attest to the problems of "level of implementation,"
affectionately known as flavorizing <gag>.
<h2>Encourage modular browsers with external rendering</h2>
<p> I want to see plug-in rendering agents that work with a variety of
browsers. This would allow me, the user, to pick my favorite browser and my
favorite rendering style. This would allow me, the programmer, to
experiment with different navigation aids without re-inventing the rendering
algorithms.
<p> A rendering agent control protocol (RACP :-) should be designed to allow
browsers to control external rendering agents. The browser would be
responsible for doing layout and management tasks, the rendering agent would
be responsible for manipulating the display of the information. The
rendering agent would understand operations such as "use this data", "render
to this window", "format for printing", "search for key", "check for anchor",
"refresh", "handle event", etc. Obviously this would have to be a
bi-directional protocol with state. We might consider several types of
RACP: one for TCP, one for OLE, one for shared memory, one for an API, one
for X property events, etc.
<p> The way I see things working is to have a public sample browser which is
capable of coordinating several sample rendering agents. People who are
interested in writing new browsers could take this sample browser and add
the navigation features they want without disrupting any rendering. Others
would take the sample browser and create new rendering agents. Rendering
images, figures, structured graphics, tables, forms, equations and scripts
could all be done with external rendering agents. I expect most text
rendering to be provided internally by most browsers, but even that should
be replaceable. Of course, someone could also decide to build any portion of
the system from scratch --- even a monolithic browser that does all rendering
internally.
<h2>Add an attribute database to documents</h2>
<p> Style sheets are a great idea. (Although I've haven't seen a detailed
proposal yet.) Let's generalize them to an attribute database (similar to
the X resource database) used to specify attributes for any rendering
agent. Attribute databases could be organized according to document type,
customizable by the user, etc. A particular document could call out a
particular database "query" or simply in-line the required attributes. Let
rendering agent authors decide what attributes are important, what their
syntax and semantics are. Users could still configure the way documents are
presented by modifying their attribute database.
<h2>Multi-part documents, Security, etc.</h2>
<p> These are all of great concern to me, but they are unrelated to this
article. In fact, I don't even know if they are part of HTML+, or simply
part of HTTP or some other Web infrastructure.
<pre>
--
Ken Fox, fox@pt0204.pto.ford.com, (313)59-44794
-------------------------------------------------------------------------
Ford Motor Company, Powertrain | "Is this some sort of trick question
CAD/CAM/CAE Process Integration | or what?" -- Calvin
AP Environment Section |
</pre>