Comments on HTML+ Request For Comments
forman@cs.washington.edu (George Forman)
Date: Mon, 31 Jan 1994 20:59:55 -0800
Message-id: <199402010459.UAA17295@hake.cs.washington.edu>
From: forman@cs.washington.edu (George Forman)
Sender: forman@cs.washington.edu
To: www-talk@nxoc01.cern.ch
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:
================================================================
1. LINKS:
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.
12. MORE SEMANTIC MARKING OF CONTENT:
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)
SUBTITLE
DOCUMENT_TYPE -- RFC, Internet Draft, manual, tutorial, catalog
DATE
VERSION
ABSTRACT
KEYWORDS
AUTHOR -- the author(s) of *this* page, not referenced pages
ORGANIZATION -- author's affiliation
POSITION -- author's title/position/role/qualifications
COPYRIGHT
ACKNOWLEDGEMENTS
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.