comments on HTML+ discussion document
Jim Davis <davis@dri.cornell.edu>
Date: Mon, 1 Nov 1993 15:35:21 -0500
From: Jim Davis <davis@dri.cornell.edu>
Message-id: <199311012035.AA02830@willow.tc.cornell.edu>
To: www-talk@nxoc01.cern.ch
Subject: comments on HTML+ discussion document
First of all congratulations to Dave for excellent work. Don't be
fooled by this email, as it contains only my complaints and
disagreements; the praise and delight are to be understood implicitly!
My main comment in that HTML+ is too big. It is beginning to resemble
PL/I (am I the only one old enough to remember this language) or
Common Lisp. Do we really need all these features, and more
important, will the browser implementors actually put them all in?
The thing about WWW is that it's very very easy to make a simple
server but it's getting to be harder and harder to make full client.
1) Re 5.2 Hypertext links. Why not drop TYPE, SIZE, and METHODS? As
you say, there's no guarentee they will be accurate. We're just
asking for trouble by putting them in the language. Yes, it would be
nice if the browser could tell me ahead of time what is at the other
end of the link but given a choice between inaccurate info and no info
I'll prefer no info. If we put these in the language, there will be
times when it is wrong and it screws someone; What's more, eventually
some clever person will demand that we build some mechanism for
guarenteeing that they stay up to date. If you really need this info
before transfering, isn't that what the HEAD method is for?
2) 5.11 Conditional Text. I appreciate the problem, having
run into it myself, but this is not the right answer. The general
problem is that different rendering is required for a printed (dead)
document and for an online (live one). HTML+ seems to have several
different solutions for the problem. There's the conditional text
and also the PRINT attribute. I would prefer to keep *both* out of
the language until a clean proposal comes in that unifies all.
I dislike conditional text because:
1) there's no guarentee that people will use it in parallel ways i.e.
to provide equivalent info for online or printing cases. There's no
guarentee the two sides will stay consistent.
2) If you are going to have conditional text might as well generalize
it to include arbitrary boolean tests. I can imagine browsers that
are neither printing not screens, e.g audio browsers.
3) I can also imagine smarter printing programs that might want
to look at the anchor to determine the proper way to print it.
3) Re 56.4 notes and admonishments
I agree with Bert Bos, the ROLE in NOTE should be a type, and not
printed. Als je kan maar het Engels gebruiken. ("Otherwise, you can
only use the english language.")
4) Re 8.1 Active areas:
you have the origin in the upper left corner (good) but the last draft
of HTTP I saw has the origin (for SPACEJUMP) in the lower left. We
are asking for trouble here.
5) 13 Indexing
I don't understand why this is even in the HTML spec. I can certainly
appreciate that document authors might want to define index hits when
writing documents, but this index info has no semantics to the
browser, so why should it be in there?
Does the definition of HTML allow me to put any arbitary stuff I want
inside a tag, e.g. can I write
<h3 ID="z23" shoe-size=19 rent="4+dollars">
If so, then I can put the "index info" in there in the same way?
6> 14.2 HEAD and BODY.
Are these mandatory? or optional?
7) Re 14.7 LINK. It's not clear to me what a browser should do
with links like REL=Previous, since a user (client) can arrive
by many paths at a given node. I would be upset if I clicked
on "Back" and landed not at the previous (historical) node but
rather the one that some author thought was previous.
8) Typos:
p2 extra space after apostrophe in "document' s text"
p 4 missing space "level one header.Header"
best wishes