siegfried at rorkvell.de
Sun Nov 5 07:56:52 PST 2006
Am Sonntag, 5. November 2006 13:59 schrieb Chris Casciano:
> I think I've also seen this behavior desired quite a bit more with
> hcard then I have with hcalendar... where you will often have the
> hcard container element spanning a fair amount of textual content.
> Sometimes the footer element, sometimes some copy with URLs that
> really shouldn't be attached to the user directly, and sometimes just
> a lot of 'random' stuff (use case of the authors card in a footer
> wrapping other meta info like rel="license", links to the validator
> or software apps home page.. or even text linked keyword advertising
> links). Though that might not be the optimal markup, I would push
> back strongly against assuming any more meaning to a link that
> doesn't have any explicit attributes.
Well at least the meaning of a link _is_ that it contains a url in its href
attribute. This is the basic meaning of a link, without any further markup,
any class or id or other attributes. It is already specified that way.
> As for class="url" vs. class="alternate" I'm not sure the value in
It's not really "versus". The meanings and purposes are different.
> that vs. multiple instances of "url". Is there a parsing issue or
> translation issue into one of the external formats that this would
> help along? It sounds useful and certainly adds more meaning on the
> markup side, but I'm not sure how it helps once the item has been
> imported or extracted.
The problem shows up, if you have a hCard or vEvent record containing more
than one link, and only one of these links is really related to that record,
the others are, as cou called it, random data. Well, i think, that such a
hCard or vEvent record, from the beginning of the container marked with
class="hcard" resp. class="vevent" up to the end of that container should
only contain data relevant for the hCard or vEvent record, plus just filling
Let's take hCard as example. There is the possibility to include more than one
telephone number. It would be possible to add "alternate" to all but one of
them. But the hCard specification already has better markup, specifying the
type of the telephone number. Still, alternate would be an idea if you
specify more than one telephone number of the same type. But i'm not sure of
how to export that to VCARD.
Now what about the url in hCard? What does it contain? There are different
possibilities of a url. One might be some http://www.bla.blub which points to
the home page. The homepage is a valid field in VCARD. So o.k., you might
consider to put this into the hCard record:
This would be a perfect legal use of hCard and the url property. It's just
that it is not very useful. Or at least you could enhance usability much by
not using the <span> element, but the <a> element. Thus you might consider:
<a class="url" href="http://www.bla.blub">http://www.bla.blub</a>
Still perfectly legal. And indeed this container contains a url. And usability
is enhanced by providing a clickable link.
But what about not putting the written url onto the page? But instead writing
the text "homepage"?
This is valid, and through using the <a> element the content of the href
attribute is by specification a url. So adding class="url" to that link is
simply redundant. And: This container does not contain a url, instead it
contains the text "homepage".
REM.:Is there a specification in VCARD to specify which kind of url this is?
Next: There are other types of urls. What about this:
<a class="email" href="mailto:someone at bla.blub">email</a>
Still legal. But still, the class="url" is not only unnecessary but not
appropriate, since the container dies not contain an url, it contains the
So exploring this, class="url" would only make sense in two very different
1. You really include a url within the container.
2. You define that "url" does not mean a general url, but specifically the url
to the "homepage". This would be a matter of definition and should be
clarified. In this case, "homepage" would be the better class name, but since
the VCARD specification already uses url, i think it's better to stick to
that. Although then url as defined here would have a different meaning than
url defined at the w3c. It would be possible, but should be clarified.
More information about the microformats-discuss