Thanks for the heads-up, I've fixed the problem now.  My CV was the first "example in the wild" and I haven't really updated it since.  Hope I'm not responsible for too many of the other broken implementations!

Great work, David!

Ryan King would know for sure, but when it comes to contact info, I don't believe it's the class name of "contact" that's required, only that the author's current contact info be marked up with hCard.

The use of the <address> element as the root element for author's hcard was, at one time, required as a way to distinguish it as the author's contact info. But due to the fact that <address> is not a block level element, it made it somewhat inconvenient to implement.

Using a compound class name of "hcard contact" might be a good way to distinguish the contact info for the author in lieu of using the <address> element.

Aye, I've been keeping an eye on the mailing list discussion.  At the time the spec wasn't very clear so I just added it in for the sake of it.  It isn't doing any harm so I'll leave it there until hresume settles down a bit.

I'm sure there'll be more settling of the spec yet!

From a parsing and long term perspective, I'd like to see a class="contact" in there. hCard is a type, "contact" defines the role it's playing within it's containing object. If a relationship isn't specified, it'll be difficult to add hCards for a new reason in the feature to accomplish some other relationship -- i.e. it closes down future development.

Note that this problem exists in the experience block also.

I've never been a fan of <address> because it tends to have a default presentation that's nasty and presentation is important.

Settling indeed. We need it! 

I really like the semantics of the <address> element.  

One of the things I suggested as a solution to the "<address> as root for the hCard problem" was that if an hCard simply contained the <address> element, that in itself would distinguish it as the author's hCard.

This would allow an author to explicitly markup their preferred contact information within that particular hCard. Some might choose to mark up the email block, others might use it to markup their phone number, and still others might choose their steet-address, etc.

Anyway, this discussion died on the vine on the mailing-list. But I am glad we're having it again here where we can focus on it. We absolutely need a solution for it. AFAIK, there have been only two solutions proposed (mine and David's) and I am fine with either.

Paging Mr. King! :-) 

David, can you elaborate on what you mean by the problem exists in the experience block also.

I sent a note the uf-dev list about this which I can't seem to dig up right now.

Essentially, the "title" of an experience unit is brought in from a hCard; however, there is no explicit class name for the hCard, so it's possible that a different hCard in the experience unit (say, the contact information for your supervisor) could be interpretted as the wrong hCard.

One of the things I suggested as a solution to the "<address> as root for the hCard problem" was that if an hCard simply contained the <address> element, that in itself would distinguish it as the author's hCard.

This would allow an author to explicitly markup their preferred contact information within that particular hCard. Some might choose to mark up the email block, others might use it to markup their phone number, and still others might choose their steet-address, etc.

I'm not sure I like the idea of parsing hCards based on their contents. It would seem cleaner design to put whatever indicator we use on the containing element.

I"m responding to this in particular because the idea of "preferred contact information" sounded familiar. There's already a vCard type (For TEL (sect. 3.3.1), EMAIL (sect. 3.3.2) and ADR (sect. 3.2.1) called PREF, which is used to mark the preferred item for each of those.

So, I don't think using the <address> element would be worthwhile for this.

(Also posted to :[http://microformats.org/discuss/mail/microformats-discuss/2006-September/005537.html])

I agree, it's not very clean. I like the compound class name idea better. Especially since, as David points out, the need to distinguish one type of hCard from another is present elsewhere in hResume.

Kenn Wilson has marked up his resume: [parsed ok - quirks: broken skill rel-tag].

Thanks for the heads-up. My rel-tags have been fixed. I had originally omitted the href attribute because, frankly, having my resume cluttered up with links to Wikipedia seemed a little pointless. My reading of the hResume spec did not say that it was required and the XHTML was valid without it. After seeing this though, I read up a little more on rel-tag and went through and added the links.

My major gripe with hResume is the need to mark up all your skills with rel-tag.  I understand the desire to re-use existing microformats, but all those links just clutter up the resume.  I'd much rather the class="skill" were required, but the rel-tag optional.  It becomes even more annoying when you have to link to a non-intuative site to conform to rel-tag (eg. wikipedia instead of http://www.perl.org/).

This is definitely an instance where microformats have a presentation impact. I would say in this case though it's not a bad thing because:

• it does define a common way for talking about skills
• we are talking about an HTML page, so links are not unexpected
  
• these particular links can be CSS styled out if need be

They can be styled out, but that doesn't really help non-visual browsers*, nor does it solve the problem of unintuative links**.

* You can just add a skip link that is styled to be invisible for visual browsers before the skills list I suppose.

** For an upcoming project I'm linking to /cv/skills/foo, and using Apache redirects to send that off to the most relevant site rather than for example Wikipedia.

I'd rather not have to do either of these, but at least there are potential solutions.

Well, a resume is a fairly technical application of a webpage. Thus, if there was a visually impaired person reading it and we lived in a world of hResumes, one might assume they'll have the technology to bypass. In fact, this might be handled by an independent stylesheet that's loaded for accessibility.

I don't think there's any requirement that Wikipedia or any one site be used consistently throughout a single resume.

Interestingly though, I'm playing with a hResume consumer and I'm using the text of the skills rather than the link itself.

I got 404 Not Found - for the link to the tool and hte code?