chris at placenamehere.com
Sun Nov 5 09:33:51 PST 2006
On Nov 5, 2006, at 10:56 AM, Siegfried Gipp wrote:
> 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
> 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.
I'm still looking for the meaning of alternate as well in these
cases, because i haven't quite figured out what its an alternate to/of.
>> 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
> class="hcard" resp. class="vevent" up to the end of that container
> only contain data relevant for the hCard or vEvent record, plus
> just filling
But that's a very bad assumption given real world content and markup
-- and that it is a bad assumption (and a worse rule) is at the heart
of my desire to keep with the current class="url" requirement. Often
the class="hcard" may be placed on a parent container for a variety
of reasons both semantically and otherwise.
I will get into examples if I have to (though the wiki has plenty of
cases of copyright or action links (download, map, etc)... But before
I go that route let me jump back to 40k feet and see if I can get you
to see if we're on the same page with the "legitimacy" of the use of
class="vcart on the block elements containing *all* of the text in
Chris Casciano has been working in the web industry since 1997, and
currently makes his living as a freelance web developer. He also runs
Place Name Here and contributes to the Web Standards Project.
Drew McLellan is a web developer, author and no-good swindler from
just outside London, England. At the Web Standards Project he works
on press, strategy and tools. Drew keeps a personal weblog covering
web development issues and themes.
The British Museum, Great Russell Street, London WC1B 3DG |
E: info at finds.org.uk T: +44 (0)20 7323 8611
The question: if I simply wrapped each of the above cases in <address
class="author vcard"></address> and linked the "obvious" links with
class="url" (emails, personal web sites, etc) but nothing else would
that be a "good" hcard semantically? How about if I also linked some
of the other content such as "disclaimer" or "© 2006" or linked
"London, England"or "Great Russell Street" to google maps? should
those links be attached to the contact information or simply be left
with the raw content? What if I wanted to explain what a web
developer was by linking to wikipedia? that's certainly fine by
semantic hypertext standards, but its not contact information. So am
I wrong for wrapping the entire line a container with class="vcard"
or do we infact need some method of explicitly stating what <a href>s
are (or are not) part of that contact information?
And these are simple example of quite compact content. Look at cases
like flickr or linked in profiles where there is quite a lot of data
about a person being displayed but as a result the "hcard" specific
elements are scattered about the entire page (or a large portion of
it).. Those cases must have a way to separate the "hcard" specific
email addresses, urls, etc from the many, many other links in the
body of the containing element (FLICKR: friends profiles, group list,
"change information", "testimonials" are all between the block with
name and location and the other block with contact / email address)
[ Chris Casciano ]
[ chris at placenamehere.com ] [ http://placenamehere.com ]
More information about the microformats-discuss