comments on HTML+ draft RFC

Jim Davis <davis@dri.cornell.edu>
Date: Tue, 3 Aug 1993 09:29:38 -0400
From: Jim Davis <davis@dri.cornell.edu>
Message-id: <199308031329.AA19040@willow.tc.cornell.edu>
To: www-talk@nxoc01.cern.ch
Subject: comments on HTML+ draft RFC
Status: RO
Let me begin by thanking Dave Ragget (and others) for the great effort
in creating the ideas and the document.  HTML+ has some powerful
features I am eager to see come into existance.  It also has a few
design decisions I would like to question...


The most important comment I have is that there is too much emphasis
on rendering.  In the draft RFC, description of a feature is often
accompanied by some discussion of how it might be rendered.  For a
particularly strong example, see the roles for the P tag.  Now either
these hints are part of the specification or they are not.  If they
are not, then they should go into an appendix.  (I feel strongly
enough about this that I will even volunteer to do this myself if you
send me the MS Word doc.)

As a further point re rendering hints, consider, please, that some of
the Internet community is blind.  Do you want to include hints to
writers of audio browsers also?

Other comments and questions, in order by section:

Re: Normal Text

why a citation better conveyed by <em role="cite"> than <cite>

Are the roles (which are English words) also to be used in documents
not written in English?

the "footnote" and "margin" roles of em are not roles, that is they
don't describe semantics, they are rendering hints.  Again, I won't
argue whether or how much HTML+ should support rendering but can we
at least agree to call hints hints and roles roles?  There is some
underlying semantics here, namely that the foot note is a comment
on the immediately preceding text; and that both are a kind of
digression.  But the decision to place at bottom of page or in the
margin is purely rendering.

I suggest that roles be spelled out, not abbreviated as in e.g.
"dfn" for "definition" or "kbd" for "typein".

the optional rendering hints for typeface (hv and tr) are mis named.
If the meaning is supposed to be "sans serif font" or "serif font"
then why not instead have face=sans-serif and face=serif.  Or
serif=yes/no?

<hr> is rendering.

when specifying size of a text field for input, which font is used for
the character units of the width and height?

for role=byline - what's the scope of this?  the whole document, the next section?


Re tabs in PRE - if someone specifies tabs with the tab tag, does this
replace the built-in tab stops at every eight characters?

General comments

In many places the document tells us that an id field can be used.  It
would be nice to have a full list of all possible places.  Should we
assume that an id is only permitted where the doc explicitly says it
may go?

The FIGD tag "allows you to give a textual description which can be
shown when the figure itself can't be".  But may/should a browser show
the material in a FIGD tag when it CAN show the figure?

Re: ISMAP.  Shouldn't the encoding also specify *which* mouse button
was pressed?

You should delete the sentence that says ISMAP is slow.  That's not
part of the spec, is it?

Re: Tables:  Why not spell it as <table> instead of <tbl>

Can one use id to refer to a table?  Can table elements include an A tag?

The first "guideline" says: "There is no need to declare empty cells
at the end of a row".  But this is certainly not a guideline, e.g. it
is not something that a browser is free to ignore.  A browser which
does so is, I think, in error.

Can a table have more than one <tt>?  Must all <tt> be before all <th>?

It seems that the designer of this feature must have intended some
semantics which the example hints at but the spec does not mention.
Note that the first two lines of the table have only three entries
(line 1 has two entries, the first spanning two columns), yet they
begin in column 2, not column 1.  I am just guessing, but perhaps
the designer intended  or assumed that one column would be reserved
on these two "header" lines, to be used below by the row headers.
As a further guess, the table's "data" begins with the first line
that contains a <td> instead of just a <th>?  And if there's a <th>
on such a line, it's a row header, and goes into this reserved
first column?

My guesses are no doubt wrong, but perhaps the document can be
extended to say what is really true?

Maybe instead of using <th> for both the column headers (in this case,
height, weight, category) and row headers (males, females) we should
have separate tags?

the <tb> tag is pure rendering.

Re: Link attributes.  Which if any of these attributes are mandatory?

Re: Change Bars.  It would be very nice to have a way to express the date/time
the change was made.  It would also be nice to have a way to express the
identity of the person who made the change.

Re: the Miscellaneous tags.  the description here makes it seem that
these are mandatory.  I think what you mean is that if they appear at
all they can only appear at the start, not that they "must appear"

Comments on the document itself.

It would be nice if the RFC had a table of contents and an index, as it
is likely to eventually become the reference manual for HTML+

It would be nice if there were section and subsection numbers
throughout.

best wishes


Jim Davis