HTML+ -- dropping & adding features

Bert Bos <bert@let.rug.nl>
Message-id: <9311041604.AA04186@freya.let.rug.nl>
From: Bert Bos <bert@let.rug.nl>
Subject: HTML+ -- dropping & adding features
To: www-talk@nxoc01.cern.ch (* WWW discussion list )
Date: Thu, 4 Nov 1993 17:04:29 +0100 (MET)
X-Mailer: ELM [version 2.4 PL13]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 4732      

The discussion on HTML+ seems to concentrate on which elements to
remove and which to add. There are three main arguments:

1) a large spec would be very difficult to implement
2) elements once added cannot be removed again
3) HTML is for presentation only, not for writing or archiving

(1) and (2) are valid reasons for being careful, and for taking the
development one step at a time. However, (1) has to be addressed
someday, because eventually we want to add more features, don't we?

(3) Is a stance that appeals to me, but it leaves a few questions. If
HTML is for presentation, what does one use for writing and storing
documents?

In fact, I've been writing docs in a superset of HTML+, and converting
them to plain HTML+ afterwards.  This allows using all the facilities
of SGML, such as shortrefs, shorttags, entities, and subdocs, while
keeping the hypertext version simple. The richer source doc can also
be used for other things, such as converting to LaTeX. My `authoring
system,' if it deserves the name, consists of just Emacs, sgmls, and
make.

Could this be the solution? Maybe. But not until there are more
authoring tools available. And it postpones solutions for non-latin
alphabets (like Dave's ISOcyr1 example) to some time in the future.

In more detail, what are the things people want to drop or add?

Drop:
a) Anchor attributes TYPE, SIZE & METHODS (handled by the
   protocol instead?) TITLE & PRINT also have limited use.
b) Conditional text. seems to introduce as many problems as it solves.
c) INDEX attributes. No function in browser. See (3) and comments above.
d) Several LINK REL types. `Guided tours' (Previous & Next) cannot be
   specified in the docs. A doc could be part of several tours! 
e) Document type subset (the top part that looks like <!DOCTYPE
   HTMLPLUS [...]>). Not needed if entities, subdocs, etc. are left out.
f) Text flow around images. Maybe just keep the special case of an
   image at the very start of a P?
g) In spite of Terry Allen's comments, I'm still of the opinion that a
   DIRectory across the page is different from a bulleted list. The
   latter is meant to be read, the former is for reference only. But
   anyway some redundant items can be dropped from the spec.
h) Q. The quote is useful for writers, but little is lost when the
   hypertext contains explicit `'.
i) WRAP attribute seems unnecessary in view of LIT
j) SEETHRU. Still too unsettled, Maybe we should wait until we have a
   better idea of what we want or don't want in the way of inline
   image display (alpha-channels? rotatable 3D?, inlined movies?)
k) L seems to be covered sufficiently by LIT, BR (for layout) and P
   (for the ID attribute).
l) `Quote by name' suggestion. Let's stick to simple hyperlinks for
   the moment. If needed we can let the server deal with it.
m) NEXTID. Might be useful for authoring, but is meaningless to the
   browser.
n) CITE, PERSON & ABBREV. Just like Q and INDEX= it is good to have
   something like this when writing, but for presentation literal
   parentheses resp. nothing might be good enough.

Don't drop:
a) HEAD and BODY. They allow the HEAD or the BODY to be retrieved
   independently, using simple SGML tools. They don't have to be in
   the doc, as long as they are in the DTD.
b) TABLES. They can't be too hard to implement, can they? Would it be
   easier without the ROWSPAN?
c) SUB & SUP. If only to keep people from using ugly IMGs instead.

To drop or not to drop?
a) U. As Marc Andreesen said, underlining is often used for indicating
   links. On the other hand, it is a common decoration in
   typewriter-style text.
b) LANG attributes. Can influence hyphenation, layout, quoting (`' ""
   ,,'' <<>>), font-selection (e.g., smaller caps for German), and
   probably other things. Do we need that yet?
c) MH. What are the arguments pro & can for this?
d) MATH. I would love to have this, but it might be a burden on the
   implementors.
e) `Document clusters' (LINK REL types such as UseIndex, Contents,
   UseGlossary, Bookmark, Parent) change the way the Web is viewed: no
   longer a flat system, but hierarchical collections of typed docs.

Add:
a) A LABEL attribute on the LI element, to override the default bullet
   with some text (as suggested by Terry Allen)



Bert
-- 
                     _________________________________
                    / _   Bert Bos <bert@let.rug.nl>  |
           ()       |/ \  Alfa-informatica,           |
            \       |\_/  Rijksuniversiteit Groningen |
             \_____/|     Postbus 716                 |
                    |     9700 AS GRONINGEN           |
                    |     Nederland                   |
                    \_________________________________|