| From: Ka-Ping Yee <[log in to unmask]>
| My argument for reducing all three to a single tag is that they all
| represent samples of machine-processed, literal text.
Actually, what I find wrong about CODE is that it doesn't say what kind
of code. The use of fixed-width, typewriter-style type for displaying
code is the worst idiocy in common typographical practice. Code should
be styled in a way appropriate to its language, which means you should
have types (or classes) like KEYWORD, VARIABLENAME, LIBRARYROUTINENAME,
etc. Too specific for HTML, I think.
| 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.
I think I disagree with this - citing other documents is something that
a large percentage of all pages do. It probably would make sense to hav
tagging for the common elements of citations. Letting the browser know
about the semantics would let it use a house style for presenting the
information. Of course, you could also make it a single element
with the data in attributes, but I think that might make some people
squirm (I think of attributes in a database-ish way as a way to
associate data; I suspect the SGML world wants its hierarchy in the DTD).
| > 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.
If you're going to do all this with classes, <EM> should turn into
something generic (as a previous discussion explored), like "TEXT".
| > S, U, BIG, SMALL: purely presentational markup. doesn't belong in HTML.
| > Agreed.
I don't think either ACRONYM or ABBREV are very useful as attribute-less
elements, but they would be more so if they had attributes so they could
associate an acronym (or abbreviation) with its spell-out, so that they
could be presented by the browser in an appropriate fashion. Given
<ACRONYM NAME="IBM" SPELLOUT="International Business Machines"> the
browser could choose to use highlighting, brackets, footnoting, or
whatever and could even automatically attach the spell-out to the first
instance of the acronym in the page while not showing it on others, if
the styling so indicated. [Same note as above about recognizing that
data in attributes may be unpalatable.]