Vanilla 1 is no longer supported or maintained. If you need a copy, you can get it here.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

Microformats support

bliteblite New
edited April 2006 in Vanilla 1.0 Help

This is of course one of those nice to have features, but it would be great if you would make Vanilla to support Microformats like hCard, rel="tag", rel="license", etc. (see for more information).

Most of the microformats are really easy to implement. The time and effort required for writing them are the only reasons they shouldn't be done :)


  • I second this suggestion. I would *really* like to be able to auto-insert rel="follow" and target="_blank" on all the links people make in HTML so I don't get link spamming.
  • my first caution is that the microformat discussion is still in its infancy. Tools are fairly simple, if they exist at all, and formats themselves are all still undergoing growing pains of some sort or another. Things are solid enough to start working with them, getting a feel for what they can offer and looking for gotchas or missing items in the formats as they're currently defined but in terms of integrating them into distributable templates it might just be a little early (but things are moving fast) are you looking for ways to enhance the templates with microformat support, or for the ability for users to embed data? As I see it these are two different areas that need different kinds of work 1) working microformats such as rel-licence and hcard into the templates (in areas like user pages particularly, where it makes sense to have the functionality of extracting the user data) This is really simple to do on the static template end, though if its a real desire to get in the default templates you might have to hurry (I haven't been paying enough attention to know if that's ship sailed alrady and Mark has finished his updates or not) 2) coming up with a good UI / tagging system to allow for users to include microformat content in their posts -- particularly useful (i'd think) would be hcalendar and hreview and similar style formats.. This can get really difficult from a UI standpoint unless you're willing to lock the options down in some fashion or provide an alternate means of authoring/editing. Might also be useful long term for interested parties to look at hatom and other related discussions to see how they could be applied to the discussion and thread listing pages. just my 2¢ after having authored some mf related plugins and other scripts and templates. oh, and target blank is ebil
  • Extensionify it.
  • bliteblite New
    edited April 2006
    Thank you for your opinions: you all seem like you know what you are talking about.

    placenamehere: I'm curious to know: what kind of mf stuff have you done yourself? It's true that microformats aren't yet too mature, but from your comment I kinda got the impression that you think the most basic formats such as rel-license and hcard might be worth implementing?

    Sorry I might sound a little too interest in mf than I should in the context of Vanilla. The idea just is so great I think it's worth chatting anyway :)

    And yeah.. Target blank is *so* evil.
  • well, i've written some scripts to handle subscribing to hAtom pages as well as a plugin for including microformat content in textpattern sites and a few attempts to include various formats into sites. The really simple formats (tag, license, etc) i can't see changing much that would make old versions obsolete. hCard I can't see changing too quickly outside of including additonal fields in the format. But hAtom, hReview, hCalendar and others I think have a greater chance of gettting modified as they get implemented more and people hit snags with their attempts to implement (see conversations like the <a href="">hatom-issues page on the wiki</a>). From my point of view things are stable enough to start those implementation attempts, get plugins out there, get 3rd party templates or individual sites implementing them -- basically things that get regular TLC and can be updated. But I'd be hesitant to, say, try and convince Mark to implement hAtom 0.1 in the default theme he's been working on the past few weeks -- because that will be locked down and distributed at some point and probably not get as much attention by a lot of users in the next year or more. (even if there are vanilla updates, admins might not apply them) But hey, you could write an extension that allows for simple inclusion of hcalendar events into posts (as an example) and if that needs to change in a month or two to include some new fields or change class names and do it without much worries. Or take the finalized theme that Mark does, edit it with hAtom 01. (or 0.2) and hcard on the user pages and distribute that seperate as a proof of concept / fork that could be included in the main codebase in the not-too-distant future. That all said, things like hatom and hcard are basically just some class names and an extra ID or two so there isn't too much harm in getting things 'wrong" or "old" so if Mark is open for including any of this stuff sooner then I'd say go for it.
This discussion has been closed.