Comments on HTML+ Request For Comments (George Forman)
Date: Mon, 31 Jan 1994 20:59:55 -0800
Message-id: <>
From: (George Forman)
Cc: dsr@hplb.hpl.hp.comx
Subject: Comments on HTML+ Request For Comments
Content-Length: 7671

	I enjoyed reading the "HTML+ Request For Comments."  I appreciate the
efforts.  Comments were requested to be sent to www-talk.  My 16 comments are
attached.  I'll be interested in the response.

Thanks to those of you who take the time,

-George Forman
graduate student, Computer Science, Univ. of Washington, Seattle

Comments on the HTML+ Request For Comments:

  The proposed attributes NEXT, PREV, and PARENT seem like a good idea.
  I have a suggestion to make these more flexible.

  Problem: The proposed attributes don't work with page sharing.  If you
  write a linked document and insert meaningful NEXT fields, I can't re-use
  one of your pages (without copying it manually), because I want a different
  NEXT pointer.  This problem also surfaces when authors want to put multiple
  organizations on the pages of a document, e.g. cronological or by subject.

  Solution: To allow page sharing, let the *parent* document specify a *list*
  of links, then NEXT and PREV depend on how you got to that document.  The
  list can simply be formed from all the hyperlinks in the parent document,
  i.e. we don't need a new HTML mechanism.  But we might want a new mechanism
  to 1) encourage browsers to implement this, and 2) let authors have
  incidental links that are not part of the sequence of pages. 
  (Perhaps the parent could even specify a *tree* of links, to override
  deeper levels in the document tree.  Dubious.)

2. INPUT: the SIZE attribute seems to have fuzzy semantics, serving for both
  layout size and input precision.  Attribute SIZE should have just one
  meaning for all tags: the size of the object in the layout.  Perhaps there
  should be a separate attribute PRECISION or FORMAT to control the allowable
  user input formats.

  This whole thing about constraining the allowable input format seems to
  open half a can of worms.  I suggest following some established standard.
  For example, scanf()/printf() formats let you specify all these things and
  more.  And it's well-tested and well-known.  Here's a nearly free
  implementation: after user entry, the browser runs scanf() with the format
  string on the user's input; if scanf() returns an error, make the user
  re-do it.

  Attribute INT: It'd be a lot better & more powerful to specify the range or
  allowable values, rather than the number of digits, e.g. RANGE="1..100" or
  more generally, VALUES="-1,20..30,999"

  It'd be really useful to allow an error *message* with the proposed ERROR
  attribute, e.g. ERROR="Value must be less than 100."

3. UNORDERED LISTS: I believe attributes should have the same
  meaning for different tags.  Applying this principle, attribute COMPACT
  wouldn't suppress bullets for unordered lists; instead, it would do the
  same thing it does for OL--- just use less vertical space.  If you want,
  add a separate attribute NOBULLETS to omit bullets.  I think it's better 
  having the attributes be orthogonal.

  Maybe the attribute NARROW should be renamed MULTICOLUMN, since that's what
  it does.  This attribute could be applicable to other kinds of lists as
  well, in the name of orthogonality.

4. PANELS: It seems like the attribute HREF should be renamed SRC.  The name
  HREF suggests something that is only fetched if the user clicks on it,
  whereas SRC specifies an included file (as in Latex \input or C #include)
  consistent with the use in: <IMG SRC="mosaic.gif">

5. OVERLAYS: There's a WIDTH attribute but no HEIGHT attribute.  How about
  allowing an explicit HEIGHT specification.  Or, the 2-dimensional layout
  size could be specified like this: SIZE="0.3, 0.2"

  How about changing the tag name of an overlay from FIGT to OVERLAY?

6. EMBED: this is a great feature.  I'm glad it's here.  2 comments:

  1. Unless the object is displayed as a pop-up, then something needs to tell
  the browser how much space is needed in the layout.  I recommend a SIZE
  attribute to say how much vertical and horizontal space to leave.

  2. It'd be nice to have a way to specify arbitrary 8-bit data that doesn't
  need interpreting for &, < and > entities, e.g. to send a pile of data down
  to the audio device without having to scan through it all substituting
  these characters.  For this type of data, allow one to specify the *length*
  of the data.  This is quick to process.

7. ENTITY DEFINITIONS: Most of these special characters are for foreign
  languages.  I suggest adding entity definitions for special symbols used by
  us technologists, e.g. math symbols from \section 3.3.2 of Latex manual: 
	==>      \Alpha    \alpha     >=    \integral   \infinity   \forall

8. ACTIVE AREAS: Question: what happens when the area clicked is inside
  multiple active areas?  I suggest using the first one in the list.
  Certainly I wouldn't choose non-deterministically nor leave it unspecified.

9. POP-UPS: Frequently the RFC suggests displaying things in pop-ups such as
  footnotes, margin notes, EMBEDs, etc.  This encourages pop-ups, and I think
  pop-ups are mostly a bad thing.  In a large HTML page, you'd get lots of
  pop-ups which are unrelated to the contents displayed on the screen at any
  given moment.  Even for small pages, you end up doing a lot more window
  managing: placing, shuffling and destroying windows.  Therefore, I suggest
  discouraging pop-ups in the RFC rather than encouraging them.

10. ALIGN:   Instead of:	align=left	align=center	align=right
  how about we just use:	left   	      center   	      right  
  Less wordy, easier to type.
  There is no programming advantage to having "align="; internally the
  browser have a single "align" variable that holds the choice.

11. ROLE attributes for EM tags: AUTHOR, COPYRIGHT, etc.
  I see EMPHASIS as separate and independent of ROLES.  I believe ROLE should
  be its own tag, not just an attribute for EM.  An author may or may not
  want to emphasize a citation.

  For automatic indexing, searching, and abstracting of HTML pages, it'd be
  good to establish important new roles for authors to include.  Here's my
  proposed list of what you commonly want semantically labeled:
	TITLE		-- (the existing TITLE tag)
	DOCUMENT_TYPE	-- RFC, Internet Draft, manual, tutorial, catalog
	AUTHOR 		-- the author(s) of *this* page, not referenced pages
	ORGANIZATION	-- author's affiliation
	POSITION	-- author's title/position/role/qualifications
	CITATION	-- (the proposed CITE role)
	SOURCE		-- location(s) where document can be found, e.g.
			   published in journal X in June 1993, 
			   UCB tech report #89...,
			   article #7251 of comp.infosystems.www, 
			   available by ftp:.....

13. FIGURES: captions & figure descriptions yield another great opportunity
  for automatic indexing.

14. TABLES: Consider what information would need to be added so that browsers
  could treat tables as datasets, i.e. use the values.  The user could then
  plot them, re-plot them log-scale, plot this table against that table,
  manipulate them in a spreadsheet....  Powerful concept.

15. LINKS:
  The link attribute EFFECT specifies whether the fetched document should get
  a new window or replace the current document.  I feel this should be up to
  the user/browser, not the document.

16. FIGURES: It's common to want multiple figures side-by-side, for example,
  to compare 3 graphs.  I suggest allowing some sort of GROUP or BOX
  construct that puts multiple figures (or general HTML objects) within a box
  side by side.