Re: HTML tags in org, name, etc

["Jeremy Gaither" <jgaither@xxxxxxxxxxx>]

> 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.

My main argument is not that vCard should be described in HTML, but that 
the content either be meta-content that can be displayed in other forms 
defined by the user.  Perhaps it is more of a question of application, 
but the vCard should not be made to seem as a seperate entity, as it 
seems now.

> 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.

I have not seen many paper business cards that come in a braile 
alternative, or many braile magazines on the magazine rack in stores.  
It seems that the digital would could be more friendly to those with the 
inability to see.  This is what the ALT tags are for.  This is why it is 
professional courtesy to supplement graphic menus with text ones.  I do 
not mean to leave those incapable of seeing graphic logos behind.  They 
are not holding technology back.  Those with the ability to see graphics 
or text formatting, and choosing not to use those alternatives are the 
ones holding back technology.  

HTML has evolved far beyond what it was intended for.  Business cards of 
any sort are not good canidates to be encoded purely in HTML as it was 
intended.  HTML, however, can be used to either augment or beautify a 
business card now, with the expanded use of the IMG and FONT tags...

Perhaps a better alternative would be to establish a way that the vCard 
object could be defined within HTML, and then attempt to promote the 
design of vCard readers that are part of browsers.  Make vCards as 
simple to use as clicking on an icon.  Blur the distinction between 
someones website and their vCard.  If vCard objects could be encoded 
within the Meta-Content of an HTML document, then browsers could treat 
them as part of the site, and not a seperate entity.  

> 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. 

I definitely agree that HTML within the content of a vCard field needs 
to be defined, or at least limited.  There would be no need for a TABLE 
or FRAME tag within a NAME field.  Breaking older implementations is a 
problem, but with the rate of software upgrades coming about, most 
individuals using the vCard would upgrade to new versions of supporting 
software rather quickly.  As long as the connection to the 'old data' 
and the 'new data' was maintained, upgrading from one version of the 
standard to another would not be too much of a problem.

Not all of the burden of decoding the vCard should fall on the decoder, 
but it should not all be held by the standard either, unless the 
standard is to define the implementation of processing certian tags.

-----
Jeremy Gaither <jgaither@xxxxxxxxxxxxx>


_______________________________________________________
Get Private Web-Based Email Free http://www.hotmail.com