[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: HTML tags in org, name, etc
On Fri, 11 Jul 1997, Jeremy Gaither wrote:
> In other words, if people are going to use vCard, then programs using
> vCards should be able to parse HTML information OUT when it is not
> needed (such as a mailing list, database view, etc), but it should be
> USED when viewing the card. If all business cards look the same, then
> what makes you pick one over the other.
The question is one of utility. The card is supposed to convey
information, not win a popularity contest. The owner may include artwork
or URL to futher information on their card. This does not mean the card
itself must be described in HTML. It is already described in vCard.
> There are web browsers for almost every platform available, and almost
> all modern platforms support graphics, text formatting, and the like.
> Clinging to old traditions keeps technology down.
I have some blind friends who would be rather upset to hear that their
inability to use graphics or formatted text is an "old tradition" that is
keeping technology down. HTML is undoubtedly preferable to some
alternatives, such as a card consisting solely of graphics. However, it
seems likely that HTML codes will be used for fonts, <blink>, and other
display features, instead of the markup features for which HTML was
designed. Genuine markup is not needed, as vCard itself takes care of
categorizing information.
There are several technical issues, ranging from application issues
(does an address have a <BODY>?) to compatibility issues (can all HTML
sequences be simply deleted without losing information?) to flat-out
problems (is an '&' the start of an entity, or an '&'?).
The addition of HTML would also stress unduly some compact vCard
implementations, as they would need to support entity lists, and
yet-another-parser to strip out HTML. HTML was not part of the original
"bargain" for vCard, and cannot be shoehorned in.
In any case, if HTML is to be used, a particular variant of HTML must be
decided on and mentioned in the standard, otherwise data compatibility
with future or past encoders may be compromised.
The most appropriate solution would seem to be variant support for fields,
so both text and HTML versions could be included. This would remove the
burden from the decoder.
--
Kenneth Albanowski (kjahds@xxxxxxxxxx, CIS: 70705,126)