LISTSERV mailing list manager LISTSERV 15.5

Help for HTML-WG Archives


HTML-WG Archives

HTML-WG Archives


View:

Next Message | Previous Message
Next in Topic | Previous in Topic
Next by Same Author | Previous by Same Author
Chronologically | Most Recent First
Proportional Font | Monospaced Font

Options:

Join or Leave HTML-WG
Reply | Post New Message
Search Archives


Subject:

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

From:

Ian Graham <[log in to unmask]>

Reply-To:

[log in to unmask]

Date:

Wed, 26 Jul 95 15:51:26 EDT

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (70 lines)




I do not agree. HTML has a history of being a semantic markup
language, with legacy markup for physical rendering (B,I, TT, etc).
Although this is not always popular, it serves an important use, allowing
other document formats (RTF, PS, Word, etc) to be easily converted
to HTML. If you eliminate B,I,TT -- and yes, S, U, BIG and SMALL you make
this type of conversion extremely difficult, and in fact wrong -- to get
the formatting you want you would have to arbitrarily assign semantic
meaning to a string without knowing if that meaning is correct, or else
drop the formatting information entirely. I therefore argue that
these physical styles should be retained.

In addition, if physical formatting were to be dropped, authors would
(as they already do) go to all sorts of extremes to get the desired effects
(inline images of "big text", <EM> to get italics, when no emphasis is
intended, etc.) which would be far worse than having some simple physical
elements that can be assumed semantically meaningless.

If I recall correctly, with HTML 3 Dave was trying to include HTML elements
that allow authors to properly do what they were already trying to do via
whacky element usage (H6 for small notes!) To my mind, physical formatting
elements reflect this requirement.

As for the semantic elements:

INS and DEL have important meanings in a legal and other contexts. One can
easily imagine a legal browser that could toggle between inserted and deleted
text to give a view a quick view of revisions. If they have such a well
understood meaning to a large community, why bury them as an attribe value
to some grab-bag element?

ACRONYM and ABBREV -- sure, put them under DFN with an appropriate attribute.
They are not yet widely used, and this does not seem too much of a streth.

CODE, SAMP KBD .. Forget it. At least CODE and KBD are already in common
use, so it would be unwise to deprecate them. Also, I agree with Peter that
KBD and CODE have sufficiently well-understood meanings that they should be
kept. If anything, I would drop SAMP.

AU, PERSON, ...... AU seems pretty distinct to me, and useful, and I've
never liked PERSON... but I don't really care one way or the other....

Q is distinct from BQ, and both are important. Bert Bos gave a great
example earlier on of the usefulness of Q.

As for using distinct elements as opposed to a single element with
attributes, this is simply a balance between beauty (attributes) and
usability (short elements are easier to type). My balance is
reflected in the above. Your mileage may vary :-)

Ian
--
Ian Graham ..................................... [log in to unmask]
Information Commons
University of Toronto


> 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



Back to: Top of Message | Previous Page | Main HTML-WG Page

Permalink



LISTSERV.HEANET.IE

CataList Email List Search Powered by the LISTSERV Email List Manager