W3C home > Mailing lists > Public > www-html@w3.org > July 1995

HTML 3: Too many tags! (was re: Psychology and usefulness)

From: Ka-Ping Yee <kryee@novice.uwaterloo.ca>
Date: Wed, 19 Jul 1995 02:24:55 -0400
To: "Daniel W. Connolly" <connolly@beach.w3.org>
Cc: www-html@www10.w3.org
Message-Id: <Pine.3.87.9507190255.A31086-0100000@novice.uwaterloo.ca>
On Tue, 18 Jul 1995, Daniel W. Connolly wrote:
> In message <199507170434.AAA09521@calum.csclub.uwaterloo.ca>,
> Ka-Ping Yee writes:
> >
> >You know, there's some very unfortunate human psychology happening
> >here.  When HTML was designed, why did they have to make <b> and
> ><i> so much SHORTER than <em> and <strong> ?
> I'll answer that by passing the buck: I borrowed the tag names
> directly from GNU TeXinfo.
> If I had it to do over again, there would only be three phrase-markup
> elements: <em>, <tt>, and <??> where ?? is b or something like it.
> They're short, almost meaningless worlets that mean, respectively,
> emphasized, machine-like, and strongly-emphasized. (pretty close to
> TeX's <em>, <b>, <tt>, though it also adds <sl> and a few others, as I
> recall...)

That would have been ideal, i agree.

> HTML is a very broad, very shallow, generic SGML application. It
> captures common communications idioms, and should not go deeply into
> technical documentation strucures -- nor annual reports, nor
> advertising idioms, nor legal document structures, nor scholarly
> document structures, nor any of the other "vertical" applications
> toward which is being pulled.

I agree with this statement *absolutely*.  It is with the same mindset
that i look at the list of "Information Type Elements" [1] in the HTML
3 proposed spec [2] and gasp in horror.

There are *way* too many of them!

	* CODE and KBD are really no more than instances of SAMP,
	    and are much to specific in application.
	* AU and PERSON are too similar to merit separate elements;
	    i think PERSON is a good idea, but i'd think more of
	    adding attributes to PERSON like ROLE="author",
	    EMAIL="...", HREF="...", and so on.  (I lament that the
	    "mailto:" URL is used currently in many cases where
	    the real meaning is to provide information about a person.)
	    But introducing <AU> would be a mistake, for it invites
	* ACRONYM and ABBREV are also far too similar -- though in my
	    opinion, marking up ACRONYM and ABBREV when you already
	    have DFN is about as useful as marking up VERB and NOUN.
	* INS and DEL are two prime examples of highly-specific tags
	    oriented at vertical applications (in this case legalese).
I'd just as soon get rid of ALL of the above tags, except for PERSON.
I really do not see the need.  Probably DFN would be more useful if
replaced by something less specific, like TERM, to indicate merely
that a term needs defining (hinting to make it look-up-able).

<Q> and <BLOCKQUOTE> are identical in meaning.  They should be the
same tag.  Whether a quotation is presented embedded or blocked out
can be specified in an attribute.

I'm also frightened at the way the list of "Font Style Elements" [3]
is growing.  Though i can see a necessity for <SUB> and <SUP> in cases 
where they are essential to the meaning, the new <S>, <U>, <BIG>, and 
<SMALL> are *strictly* presentation tags, and don't really belong in HTML.  

As per the discussion above on psychology and usability, the smallness
and apparent convenience of <U>, <S>, and <BIG> in relation to more useful 
tags like <PERSON> continues to have me worried.

[1] http://www.w3.org/hypertext/WWW/MarkUp/html3/logical.html
[2] http://www.w3.org/hypertext/WWW/MarkUp/html3/CoverPage.html
[3] http://www.w3.org/hypertext/WWW/MarkUp/html3/emphasis.html

Ping (Ka-Ping Yee):  2B Computer Engineering, University of Waterloo, Canada
kryee@csclub.uwaterloo.ca | 62A Churchill St, Waterloo N2L 2X2, 519 886-3947
CWSF 89, 90, 92; LIYSF 90, 91; Shad Valley 92; DOE 93; IMO 91, 93; ACMIPC 94
:: Skuld :: Tendou Akane :: Belldandy :: Ayukawa Madoka :: Hayakawa Moemi ::
New! <http://csclub.uwaterloo.ca/u/kryee/> Yeah, i finally made a home page.
Received on Wednesday, 19 July 1995 02:49:55 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 30 April 2020 16:20:15 UTC