Content with Style

Web Technique

Figure microformats

by Matthias Willerich on November 20 2007, 08:28

Recently I’ve built a very small and compact project, an 8-page static website actually (first time I’ve built anything static in about 7 years!), and I took the opportunity to get a bit deeper into the microformat madness that seems to be so en vogue since the last year or so.

hCard yay, figure nay?

While the whole hCard/vCard thing for contacts is a very nice and half-decent working solution, the discussion for image/figure markup is just confusing.

The issues are that some solutions are worrying mostly about positioning, others about specific output formats, for example for feed readers (also here).

And then of course there’s the solution by Edward O’Connor that wants to follow the html 5 draft as closely as possible, which is the reasoning I could follow the easiest, because it’s also, in my eyes, the one closest to the concept that was used for the hCard.

Break it, fix it

I started using a variation of it, and the first thing that annoyed me was that I did want to mark-up caption and credit individually, but I needed to position it quite freely as a block. The suggestion on the microformats wiki would allow for individual positioning, the solution at A List Apart seemed a bit over the top, so I adjusted the original idea as follows:

<div class="figure">
  <img src="look_up_dere__small.jpg" width="400" height="602" alt="Matthias and lots of blue sky" />
  <div class="legend">
<p class="caption">
        Matthias and lots of blue sky
<p class="credit">
  <abbr class="type" title="Photograph">Photo</abbr>
  &copy; <cite>Matthias Willerich</cite>

This follows the html 5 draft as per suggestion on one hand, even more so because “legend” is used, on the other it allows me to specify caption and copyright individually, but I have the freedom to style and position it anywhere together or individually.

It took me a while to understand what Edward meant by “This has block-level elements with inline-level siblings, which is gross”, until I read Anne van Kesteren’s opinion about Markup content models.

I would’ve followed what he’s saying, but at that point my project was already out the door. Nevermind, here’s a suggested amendment:

<div class="figure">
  <p class="image"><img src="look_up_dere__small.jpg" width="400" height="602" alt="Matthias and lots of blue sky" /></p>
  <div class="legend">
<p class="caption">
        Matthias and lots of blue sky
<p class="credit">
  <abbr class="type" title="Photograph">Photo</abbr>
  &copy; <cite>Matthias Willerich</cite>

what’s the benefit?

With all this highbrow talk I don’t want to miss the point that I’ll never be in the situation again where I’m creating a template with text information associated to an image and I just don’t know how to do it right. This had been bugging me forever! With all the other concepts I just default to when I see a screen design the first time, this one fits right in. Here’s a little example page to have a look at how flexible this can be used.

Back to the highbrow future

Still, it left me wondering if I’m breaking a structure that’s used in other places; but I couldn’t find any (if you disagree, now is the time). If there was nothing using the figure markup, hell, why think about it in the first place, and not just throw together any old image and paragraph? Now, I was at that point with the hCards a while ago, but since then an hCard extension for firefox has come along, and with the current version it’s actually reasonably useful. I also agree very much with Dan Cederholms feedreader train of thought about how it could be used. While his article is already 2 years old, and not much technical seems to have happened in between, it doesn’t mean that its theoretical meaning isn’t picked up and formatted or used otherwise in the future.


Although they’re spread out all over the article, here’s the reading list that helped me with my conclusion. Have fun reading and let me know what you think.


  • Interesting approach. And thanks for the write up. Images and figures have been one issue I’ve been having trouble with as well.

    A related issue is what you do when you develop a website for a client. There’s no WYSIWYG editor in the universe which spits out this kind of microformatisch markup :) So the only alternative is developing something like this and making them use that markup. Ussually I end up having a simple div box for the image and the caption.

    by matthijs on November 22 2007, 10:12 #

  • Interesting—glad to see this topic continue to be fleshed out! I noticed that you didn’t cite my piece on this subject? Just wanted to make sure you read my take (and the interesting discussion that followed):

    As for your approach, let’s get it on the wiki!

    From your later example, this is what I see as your figure DOM:


    That seems somewhat restrictive and not altogether based on existing behavior (remember, that’s a core aspect of the microformats process). I admit that I haven’t followed process perfectly myself, and intend to do better—and your example actually serves quite well to illustrative and example in the wild, however, going beyond images, I think “illustrative” figures in general needs to be considered… how does your approach apply to tables, video, or audio? I’d like to see examples marked up if you’d be willing…

    Oh, and I do worry about the <p class=image> thing…. why not just make the .figure img have the style of display:block?

    by Chris Messina on November 25 2007, 17:30 #

  • well, I can’t think of one right now either, but you could build little wordpress plugins that give you some sort of dialog to add addresses hCard style into a post (similar to these flash video plugins).
    Because figure markup does (so far) not have that many options, it would be even easier, but using uploaded images within a plugin context is a bit tricky.

    by Matthias on November 22 2007, 19:30 #

  • I’ve tried to find a nice accessible table example, and of course, table comes with a caption element; mmm, now how would that work?

    by Matthias on November 27 2007, 05:03 #

  • Hi Chris,

    First of all thanks for your comment. And now I’m going to punish you with this retaliation!

    I’ve followed Edward’s/Anne’s reasoning behind the p.image, which is that you shouldn’t mix block and inline elements on one level. Changing the behaviour of an element in css (display:block) doesn’t solve it on an html level.
    Where I agree with you is that it’s, hmmm, possibly over the top? If it was down to me before I read Anne’s concept (and the way I used it in the project was before I took on this issue), I wouldn’t have bothered.
    The DTD allows this kind of html structure, the code validates. Yet it seems wrong for some. So what would be the better way: taking it out, and thereby having less than perfect html (and, actually, one container less for different kinds of media, such as the mentioned tables, video or audio) for the sake of more people getting their heads around it; or leaving it in, risking that a lot of people don’t understand the issue behind it, and it’s consequently accepted and adopted less.

    About other-than-image content: I don’t see an issue at all with video or audio, given that both usually run in their own kind of player. The point of using other media would actually be one for the block container around the img. About tables, well, there’s already a lot of ways of describing a table, it would be great indeed to see a fully annotated table, that would then be dropped in the currently named p.image. I’m not a native english speaker, so I’m getting a bit weak around the terminology here. Of course it shouldn’t be called p.image if there’s other content in it. If you’re talking images, audio, video, you’d get away with, but as you say it needs to be able to allow for any content, really.
    What’s a good general word for the to-be-described content?

    This is getting the longest comment ever… finally about why I didn’t quote your article (I just re-read it): There’s a strong case for not muddling up presentation and code structure. I want to get to the right way (if only right in the things that I personally do) of marking up figures first, and then I’ll worry about where it’s sitting. As you wrote, I wouldn’t add alignleft, alignright and center in general use; as I’d prefer neutral classnames (although, in the real world, case-to-case, there’s good reason for doing exactly that; and that’s what I read out of your comments as well).
    But what I don’t understand is why the presentation of a figure block (or an image or whatever) even needs unifying? Isn’t the idea of microformats that you create machine-readable tags that, once parsed, could be displayed in any way? And, again, reading from your comments, if the positioning of an image is important for the context, then why not use natural language “left”, “right” or “center”?

    by Matthias Willerich on November 26 2007, 07:26 #

  • I think the class that indicates the microformat should be seperate from any layout classes, i.e. class=”figure layout-a” ... on a personal note I couldn’t be bothered to be fuzzed about block and inline elements mixed … if the DTD allows it and you save an element, then it’s legitimate. But that’s just my 5 p.

    by Pascal Opitz on November 27 2007, 06:07 #

  • Since I cant edit at (and dont want to register) I suggest you to consider license information using rel=”license” from Atom [1]. Check Mark Pilgrim’s blog to see how he makes clear the license for each picture he takes from Flickr [2].


    by Federico M. Panico on December 11 2007, 23:20 #

  • I\'ve just had a look at what has been happening on the Microformats-Wiki, and it seems that Toby Inkster has taken on the subject and done some nice consolidation work over the last year, pretty much incorporating my suggestions. Leaves him and me and the rest of the world with making it more generic, incorporating other forms of content such as (but not limited to) tables or code listings, to make it more conform with the HTML 5 figure element scope. Watch out for a new post about this soon, feel free to suggest improvements or examples in the meantime.

    by Matthias Willerich on February 15 2009, 21:23 #

  • I think the class that indicates the microformat should be seperate from any layout classes, i.e. class=”figure layout-a” ... on a personal note I couldn’t be bothered to be fuzzed about block and inline elements mixed …

    by amber jewellery on March 24 2009, 15:44 #