Re: Standardizing new HTML features... WE'RE INTERESTED!

Rob Raisch <raisch@ora.com>
Date: Tue, 27 Apr 1993 17:19:05 -0400 (EDT)
From: Rob Raisch <raisch@ora.com>
Sender: Rob Raisch <raisch@ora.com>
Reply-To: Rob Raisch <raisch@ora.com>
Subject: Re: Standardizing new HTML features... WE'RE INTERESTED!
To: Dave_Raggett <dsr@hplb.hpl.hp.com>
Cc: www-talk@nxoc01.cern.ch, mcrae@lib.ucsf.edu, Dale Dougherty <dale@ora.com>
In-reply-to: <9304271134.AA02979@manuel.hpl.hp.com>
Message-id: <Pine.3.03.9304271538.K11156-d100000@ruby.ora.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII


Dave,
	O'Reilly and Associates is *extremely* interested in helping you with
this effort.  We have a number of products in development which use HTML as
their technology base.  We see the future development of HTML to be of great
importance to our efforts.

	You mention the following as important issues in the future of HTML:

<QUOTE AUTHOR="Dave_Raggett <dsr@hplp.hpl.hp.com>">
    o   nested lists (e.g. OL within UL, UL within DL, ...)
    o   embedded images with text flow etc.
    o   query forms
    o   tables
</QUOTE>

	I would suggest that lists and text flow are really exclusively
rendering issues.  When I want to make a nested list, I may wish to write it
thusly:

<EXAMPLE>
	<UL>
	<LI>First Term, First Level.
	<UL>
	<LI>First Term, Second Level.
	<LI>Second Term, Second Level.
	</UL>
	<LI>Second Term, First Level.
	</UL>
</EXAMPLE>

	And I might *EXPECT* that it would be rendered as:

<PRE>
		First Term, First Level
			First Term, Second Level
			Second Term, Second Level
		Second Term, First Level
</PRE>

	
<COMMENT> And in fact, under Xmosaic, the *right* thing is done, with the
addition of some nice bullets to differentiate the different levels of the list.
</COMMENT>

But since there is no rendering information in HTML, and by definition there
cannot be, how the terms appear on the screen is left up to the renderer.  For
example, the www text mode browser renders these lists thusly: 

<PRE>
		First Term, First Level.
      
		First Term, Second Level.
      
		Second Term, Second Level.
      
		Second Term, First Level.
     
		[End]
</PRE>

	Since there is no definition of how things *must* look when presented to
the user, both behaviors are absolutely correct.

<HYPOTHESIS> Any expectations of how an object is rendered will be incorrect in
some instance of the use of that object.  Thus, all expectations of an object's
appearance are generally inadvisable.  </HYPOTHESIS>

	I would also suggest that the requirements of 'text flow' around
embedded graphics are also rendering time issues and should not effect the
definition of HTML. 

<OPINION> I believe that HTML, like it's progenitor SGML, should be simply a
method of describing data, not how it should appear on the screen.  In fact, I
think that this is exactly the sentiment which Tim Berners-Lee has expressed to
us all regarding his vision of HTML. The formatting of lists and the flow of
text around graphics do not fit this definition.  If this is an incorrect
assessment of the role HTML needs to serve I would be very interested in hearing
from others. </OPINION>

	The next elements on your list, query forms and tables, seem to be a
little clearer but pose similar problems. 

	To describe a "form", in the traditional sense, implies it's layout
simply based on the fact that a "form" is the presentation of information in a
controlled layout or format.  

<HYPOTHESIS> A form or table cannot be specified in HTML without breaking one of
HTML's first principles since forms and tables are descriptions of the
appearance of information in relationship to other elements and not the
description of information in terms of type and content. </HYPOTHESIS>

I believe that we can ask questions:

<EXAMPLE>
	<QUERY DEFAULT="Red" OPTIONS="Black|Blue|Red|Green|White">
	What is your favorite colour?
	</QUERY> 
</EXAMPLE>

since this is the tagging of an entity (description of data), with certain
special behaviors or attributes defined, I would think that this would be a
natural for HTML.

But, the moment we start talking about collecting this information into forms or
tables, with set, defined  relationships between elements, we are treading on
very thin ice, indeed. 

<ASIDE> I hesitate to mention it, but SGML has few (if any) provisions for
handling tabular data, and there are a lot of people who really want to be able
to do this, desperately! </ASIDE>

<ASSERTION> The organization of information into tabular form is intrinsically a
render-time issue, not a representational one. </ASSERTION>


	I am very interested in these issues, both from a personal standpoint
and a company one.  I have some ideas regarding a possible solution which I will
send out under seperate cover.  Thanks for your time.


 <SIGNATURE>	Rob Raisch, O'Reilly & Assoc.	</SIGNATURE>