Comments on HTML Internet Draft

forman@cs.washington.edu (George Forman)
Errors-To: secret@www0.cern.ch
Date: Fri, 4 Feb 1994 01:37:48 --100
Message-id: <199402040035.QAA22673@june.cs.washington.edu>
Errors-To: secret@www0.cern.ch
Reply-To: www-talk@www0.cern.ch
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: forman@cs.washington.edu (George Forman)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Comments on HTML Internet Draft
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 2437
Tim,
	I've just been reading your HTML Internet Draft.  Thanks for all
your good work on HTML.  I have 4 comments below.

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

======================================================================


1. I propose a new Anchor attribute SIZE that says approximately how large
the remote object is: SIZE=8KB, SIZE=5MB, SIZE=1GB.  This information is
useful feedback for readers: if an object is large, people want to know
*before* they fetch it.

This attribute is similar in flavor to the attributes TITLE and METHODS.
	1a. they can become inconsistent with the remote object, but that
	   doesn't mean they shouldn't be supported.  The size of most
	   objects is relatively stable, and also, objects typically grow
	   instead of shrink, so the SIZE gives an estimate of the lower
	   bound.
	1b. yes, this information *can* be obtained from the remote 
	   HTTP server, but no browser is going to bother to do that
	   because there is a lot of overhead involved.    Much better to
	   have it specified in the document.


This attribute should also be supported for LINKs and IMGs.  
Users could then tell their browsers to fetch all IMGs with SIZE < 10KB,
but don't fetch the larger ones, for example.


Perhaps it should be called DSIZE or WEIGHT so as not to be confused with
layout "SIZE" attributes such as used by HTML+ INPUT fields.





2. Link Relationship Value:   Precedes

For consistency, I feel the word PRECEDES should be replaced with
FOLLOWS, as in "B FOLLOWS".  As it is now, it reads as though it had the
opposite semantics: "B Precedes". (This change is consistent with the
rest of the relationship values; they apply to the thing being pointed
at, as in "B is a REPLY", "B is a SUBDOCUMENT".)

Also, many people misspell PRECEDE as PRECEED.

Note: I'm not changing the semantics, just the syntax.  You've got
the right semantics; I think REL=Follows will be more commonly used 
that REV=Follows.  






3. REL and REV look so similar, you can bet there will be lots 
of mistakes made, and it will be difficult to notice the bug.  
What about changing REV to REVERSE?





4. Link Relationship Value: Supersedes

Similar to #2 above, I think the word SUPERSEDES should be replaced with
OBSOLETE or SUPERSEDED, i.e. "B is OBSOLETE" or "B is SUPERSEDED".  As it
is now, it reads as though it had the opposite semantics: "B Supersedes".