Re: ACTION re: HTML 3: Too many tags!

Ka-Ping Yee (
Wed, 26 Jul 95 14:27:22 EDT

On Wed, 26 Jul 1995, Peter Flynn wrote:
> Summary: why we don't need....
> CODE, KBD: redundant. Use SAMP.
> <em rend="scream">No</em>. CODE and KBD are _quite_ different. If
> anything is to go, it should be SAMP, which has no meaning. Ideally I
> suppose one ought to have <input type="foo bar"> and <output type="bar
> foo"> so you can arbitrarize (heh:-) the whole shebang...

Certainly i believe that CODE, KBD, and SAMP are not *all* necessary.
Are we agreed that at least one should be removed/collapsed away?

My argument for reducing all three to a single tag is that they all
represent samples of machine-processed, literal text. (This by no
means restricts all three to the same rendering!) But it seems
inconsistent to single out CODE and KBD as particularly important
instances of sample text -- rather, the classification of the *role*
of the text has an indefinitely large scope, and makes more sense
indicated with in a CLASS or ROLE attribute.

> AU: too specific. apply attributes of all kinds to PERSON instead.

My problem with AU is pretty much the same as that with CODE. It is
one specific example of how you can specify a person's role. Why
should <AU> be a tag, while <EDITOR>, <PROGRAMMER>, <DESIGNER>,
<ARTIST>, <GROCER>, <BAKER> ... are not? Again the scope is infinite
(and infinitely divisible into more precise classifications), and
makes more sense as an attribute.

> PERSON is a wholly different thing and stands alone.

<PERSON>, on the other hand, refers to a human being, which is quite a
singular, separate classification. We can define attributes that make
sense for <PERSON>, like EMAIL="...", SMAIL="...", FAX="...", TEL="...",
HOMEPAGE="...", etc. -- and then these attributes will continue to make
sense for authors. With attributes like these, we can then use automatic
tools to find and contact people. Rather than adding these attributes (i
want to find out about this author so-and-so) to two tags -- one general
and one arbitrarily specific -- it's simpler and more effective to treat
an author as one possible role of a <PERSON>.

> <em rend="shout">No</em>. AU if anything ought to be within CITE,
> along with a reasonable BOOKTITLE and PUBL. IMHO.

I agree that citing references is a very useful ability. But the
problem with this is that we'll need a good six or seven tags (let's
say we don't limit it to just books -- PUBNAME, ARTICLE, AUTHOR, PUBL,
PUBDATE, LOCATION, maybe SECTION or PAGE) to get complete reference
information. And by that point it's become way too specific to be a
part of HTML on the level of each being separate tags. You'd need to
include a separate section in the DTD to define what the structure of
a citation is, and that's probably going overboard.

So i thought about this problem for a while, and finally arrived at
this: what's a citation anyway? It's just another reference. Perhaps
what we really need for a citation is -- look out -- a URL! Now i
know i'm not familiar with a popular worldwide standard for library
catalogue searches, which makes this a little different from other
URLs (all of which have protocols defined in RFCs somewhere). But the
more i think about it, the more sense it seems to make! It's a
reference to other information which, given some configuration, can
be machine-processed and automatically lead to the information when
selected by a user. (Apologies that i forget who it was, but i agree
with the person who preferred <A REF="..."> to <A HREF="...">.) Oh,
and further apologies if the correct term should have been "URI". Help?

> ACRONYM, ABBREV: redundant. Use DFN.
> With attributes, yes.

Yes -- sorry i didn't state that explicitly, but i meant "use attributes
instead" for most of the redundant tags.

> INS, DEL: too specific. apply attributes to P instead.
> No, you may want to <del>remove short phrases</del> instead.

Indeed. <P> is a bad choice, since it's structural. Probably, (as
suggested in response to the thread on "obsolete" and "new"), <EM>
would be a better choice.

> S, U, BIG, SMALL: purely presentational markup. doesn't belong in HTML.

> Agreed.

So far i have only heard agreement with respect to removing S, U, BIG,
SMALL, ACRONYM, and ABBREV. There's been some agreement to remove CODE
and KBD and some dissent, but at least we are perhaps agreed that CODE,
SAMP, and KBD together are redundant. I still feel quite strongly about
removing AU, and though not as emphatic i think removing INS and DEL can
be justified. Other opinions and arguments?

Ping (Ka-Ping Yee): 2B Computer Engineering, University of Waterloo, Canada | 62A Churchill St, Waterloo, N2L 2X2, 519 886-3947
CWSF 89, 90, 92; LIYSF 90, 91; Shad Valley 92; DOE 93; IMO 91, 93; ACMICPC 94
! Hiyama Hikaru ! Ayukawa Madoka ! Amano Ai ! Hayakawa Moemi ! Tendou Akane !
draft Video Girl Ai manga full-translations posted on vgaiml-l@ualtavm.bitnet