When using the Operator extension and choosing to export the contact and open with Windows Contacts (on Vista), none of the address fields are filled out. In your example, I get values for name, email address and URL, but none of the street address, locality, region etc.

I’ve had a similar problem when doing my own Microformats examples in the past – everything works OK except for whatever is contained in the element with the adr class. Presumably this is a problem with Windows Contacts rather than Microformats?

I’ve just worked out what’s wrong with this example (and all the hCards I’ve been doing up until now): for an address to show up in your exported contact, you need to specify whether it’s either a work or home address with (for example)

<span class=“type”>Work</span>

just as you have to do the same to distinguish between fax and phone numbers etc.

“for an address to show up in your exported contact, you need to specify whether it’s either a work or home address”

That sounds like a limitation of the tool you’re using then, John. The spec doesn’t require a type to be set. In fact, adr, tel and email all have default types which should be implied if no type is specified (if I’m reading it correctly).

Mat, microformats are designed to add additional semantics to HTML to help a document author communicate the meaning of the content when HTML’s own semantics are not expressive enough.

Therefore it makes not sense to add them with JavaScript – it’s totally the wrong layer. Whilst it’s true that some of these little utility parsers run in a browser and therefore have JavaScript available (in which case why touch the document at all, right?), most parsers won’t have JavaScript and a DOM to work with.

Google and Yahoo both have some pretty neat microformats-based search tools in development that you can play with and get an idea of how useful structured data really is.

A good tutorial and introduction for those that haven’t gotten into microformats (or CSS 3) yet.

Having said that, I’d have to disagree with your markup for the address. An unordered list is completely unsemantic for an address and the html that was generated automatically is far better. At least it’s not using the <address> element as lots of people tend to (that’s for the authors address, not general addresses in case anyone asks the question)

Good article though – I’m definitely going to be playing with some progressive enhancement this Christmas :-D

Fabulous I’ve been meaning to do some research on this micro formats thing. Embarrassingly I’ve only recently discovered it by its name. Great introduction for me thanks a lot.

This is definitely going to be part of my new portfolio. Nice with the css3 addition there as well.

Great article, Elliot :-)
I’ve been meaning to finally look into Mircoformats for ages – for far too long…. now you’ve got me started.
Thanks :)

Nice work with the progressive enhancement, you could of used moz-transition… for the FF3.1beta users out there.

Box-shadow could of been used to lift the card off the background (except it is not progressive enhancement for Chrome users when combined with border radius)

The Firefox 3.1beta, nightly Webkits and Opera 10 alpha are beginning to show what can be done with CSS3 but it needs to be progressive enhancement.

That hCard Creator is back! What a cute tutorial you wrote :D

I concur with Ben. I don’t see why an address should be marked up with an unordered list when addresses don’t have any connection with lists.

Very nice, too bad the full impression can still only be seen in Safari.

How I wish I had read something as easy as this when I first tried to implement a vCard within my own site, the hCard creator would have stopped me messing about trying to get the thing to work. However after reading John Faulds comment, perhaps it wasn’t my fault?

Onto progressive enhancement, as we know you can round corners of elements by using -moz-border-radius and -webkit-border-radius and when I was implementing this into a site yesterday I started to wonder if I could implement this with a border and found that it only worked to a certain degree.

Although the outside corners were rounded, the insides were still pointed and hard on the eye. This might sound really stupid but is there something along the lines of -moz-border-inner-radius or something which would help me overcome this problem? I don’t think it’s possible in the first place, so I’m not holding my breath.

Great article Elliot, insightful as always.

“Very nice, too bad the full impression can still only be seen in Safari.”

Well, that’s sort of the point, Kaske. The idea is that we’re starting with basic markup describing the content. We then layer on some simple CSS for browsers that support it. On top of that we layer some more advanced CSS for browsers that support that. As browsers get better and implement more of the available specifications, then users of those browsers will see the finer points of the presentation. If not, what they get is just fine too. That's what progressive enhancement is about.

As for the use of a list for an address – I can see the argument for that. An address is a list of places ordered from specific to global. I’d argue that the order is important for the address to make sense, so perhaps an OL would be better than a UL. However, we could debate these tiny points all day, but that’s not really what this article is about.

@ Ben & Botclock: What Drew said.

@ Kaske: Again… what Drew said.

@ Jack I’ve found this problem too. I might be wrong but I think it’s due to the not-quite-perfect implementation, but if anyone knows of a fix, please feel free to jump in!

@ Drew: Cheers for sticking up for the progressive enhancement and list-based markup! You said it better than I ever could have. And, in hindsight, I think you’re right about how it should’ve been a <ol> rather than a <ul>. Good call.

Great article Elliot and nice to see designers embracing microformats.

I can see the argument for using a list but in which case howsabout a definition list? This will maintain a semantic (human readable) association when microformats are unavailable through name-value associations and the definition terms can be hidden/styled appropriately with CSS if required.

For example:
<dl>
<dt>Street address</dt>
<dd class=“street-address”>25 Laughingallthe Way</dd>
…
</dl>

Just a thought…

Cole – this article on definition lists by Mark Norman Francis is good reading.

To be honest, this sort of semantic nitpicking is one of my least favourite things about being part of the web design community. Semantics are a practical tool and make your documents meaningful and portable. What they are not is a weapon to beat other designers round the head with.

As Drew already pointed out, a list is a perfectly valid match for an address. A group of items, in a specific order, which are grouped for a specifc purpose? That sounds like a list to me!

As for the <address> thing – I’ve always been in two minds about this. On one hand, I know exactly what the spec says the address element means (how could anyone not? It gets mentioned at least once in any discussion of hCards – in this case, even without being in the example). On the other hand, I personally feel that if you’re going to defend semantics so thoroughly, it’s probably the most meaningful element (from a pure semantics point of view, that is). I’ve always gone with the specs on this, but I’ve always thought it represents a decision between sticking religiously to (X)HTML specs, and marking up your document as semantically as possible. Just an idle thought.

First comment on here, by the way, so I’ll just say well done on the redesign. It’s a bit special!

Take care,

Andi

Thanks @drew

Had read Mark’s article already but not entirely in agreement. I accept that in the rigours of the HTML spec the use of DL in the above example would probably be inappropriate but faced with the limitations of markup we are all having to examine the ways in which we can use the currently available HTML elements to add meaning to our content. That, of course, is the whole point of microformats – to add value where the current HTML specifications do not allow and to make that content accessible to machines.

Yes, the definition list is open to abuse (dailogue provides an excellent example) but personally I would be happy to use it for this situation where we are establishing unique name/value (term/description) pairings within that particular list, essentially defining that persons address/contact details.

@Cole – I would have thought that the problem with using a definition list is less about it being inappropriate and more about it being overkill. Addresses are already human-readable – we recognise them for what they are without labels on each line. The value of labelling is only to make an address machine-readable, and a definition list won’t help with that.

Microformats just seem so obtrusive to me. Although a class isn’t a behavior, the same principles apply, and the code just gets so messy.

If, like in this example, you know the number of entries and their order, why not traverse the DOM (I’d use jQuery :eq(index)) and add the span classes with JavaScript. That way you keep your HTML clean. Microformats are an enhancement, so requiring JavaScript makes sense to me.

p.s. I feel an ordered list is the most semantic markup to use for the address.

Exports fine to MacOS Adress Book App. Using Firefox and Operator add-on

“That sounds like a limitation of the tool you’re using then, John. The spec doesn’t require a type to be set. In fact, adr, tel and email all have default types which should be implied if no type is specified (if I’m reading it correctly).”

The tool I’m using is the Operator extension for Firefox. It gives you the options of exporting contacts to Windows Contacts or Yahoo Contacts or opening a map in Google, Yahoo or MapQuest. Exporting to either of the two contacts options leaves the address fields blank; exporting to any of the maps apps returns the address.

So which is incorrect – the markup or Windows/Yahoo’s implementation?

I took the cue for adding a type class to the address yesterday after downloading Oomph – http://visitmix.com/Lab/Oomph – which is used to reveal Microformats info on pages. They use the type class and the address detalis show up when exporting a contact.

Whether it’s part of the spec or not, I think it’s worth mentioning that this seems to be what’s required to enable this functionality.

In the case of hCard, how would I mark up the different lines of a “street-address”?

I don’t agree that the lines in an address comprise a list, any more than that a series of paragraphs comprise a list.

I’m much more of a sceptic these days about the usefulness of microformats (yup, I came as the Grouch), but I’d love to be converted back to a more optimistic side. Helping search engines index your pages sounds like one of the better uses I can think of. You know what would be another use? Microformats in HTML email (something this example would suit!). A little widget in, say, Gmail, that can grab vCards and write an hCard right into the email. Gmail could parse out any microformats in received emails, too, and present the information in whichever way was appropriate. Of course, things would be better if we could just expect our email client to recognise addresses like Apple Mail! But until then, there’s always microformats.

@ John Faulds: While Drew is much better qualified to give you an in-depth answer about this than me, I will just say that I use Operator for Firefox as well, and the contact exports just fine for me… and automatically adds it to OSX’s Address Book app without a problem. I can only guess that it’s therefore a problem with Windows Contacts, Yahoo Contacts, or perhaps Operator / Firefox on Windows.

Great article Elliot.

Microformats are on my list as one of many improvements I want to implement into my site builds however, you may be able to answer a question that I’ve been asking myself since I started research into Microformats.

And that is whilst reading a presentation on Microformats one slide stated, and I quote:

Avoid “class-itis”

Now, surely thats how Microformats are set/work by adding descriptive classes to you semantic markup.

Maybe I’m missing the trick here but thats how I read and understood the explanation of how Microformats work.

Anyone else thought this too?

“Avoid “class-itis” – Now, surely thats how Microformats are set/work by adding descriptive classes to you semantic markup.”

Classitis usually refers to the habit of needlessly sticking a class on anything and everything, (e.g. a class of “normal” on every paragraph) rather than using appropriate selectors to target parts of the document by context.

Microformats do use a lot of class names, but for a specific purpose, and to add value. No one wants to bloat their pages, but it’s not bloat if it’s adding something useful, no more than a large image in a page is bloat if it’s useful content.

Correction to my previous comment I suggested transitions for FF3.1beta. that is one CSS3 property not supported by FF3.1b. (I will claim getting confused between transformation and transition – lots of new CSS3 to learn).

Chrome has improved CSS3 support, and now supports transition, unfortunately border-radius + box-shadow bug still exists.

Classitis to me is sticking class name on everything to style them, and not understanding the best way to use CSS selectors to get the desired results. Why use p.normal when #content p gets the same results.

As Drew said class names for Microformats is for a specific purpose and add values.

And I am enjoying the conversation on semantic mark up of addresses. Most humans understand visually styled data, but not everybody and not computers.