Development:Planning:Microformats

From Camino Wiki
Revision as of 20:45, 15 September 2006 by ChrisCasciano (Talk | contribs)
Jump to: navigation, search

Contents

Background

Microformats are a collection of standards or conventions for marking up data with XHTML to allow that data to be more findable and reusable. Examples include hcard for marking up contact information and hcalendar for marking up events. That data can then be extracted from the HTML document via XSL, DOM manipulation or other method and repurposed or exported into other applications (like iCal or AddressBook.app) or saved in some intermediate format.

Microformats aren't a new technology or other datatype embedded via XL nsamespaces or other method. All the magic is done via XHTML attributes (class, rel, title). This simple hcard creation tool provides a good visual example of how this works at the markup level.

Where Camino fits into the picture is up for discussion, but some form of discovery of formats is the first goal followed closely behind by export or hand off to other tools, or in some cases handing inside of Camino itself.

Links

Microformats List

For starters, here's a list of different accepted and/or proposed microformats. Each type of data should be discussed somewhat independently in terms of what handling (if any) is done inside Camino.

Specifications

  • hCalendar
  • hCard
  • rel-license
  • rel-nofollow
  • rel-tag
  • VoteLinks
  • XFN
  • XMDP
  • XOXO

Drafts

  • adr
  • geo
  • hAtom
  • hResume
  • hReview
  • rel-directory
  • rel-enclosure
  • rel-home
  • rel-payment
  • Robots Exclusion
  • xFolk


Initial Brain Dump by User:ChrisCasciano

There are a lot of items listed above, all in various states of stability and implementability, but I see them generally breaking down into three categories:

  • Data you'd want to hand off to or export to another application (hcard, hatom, hcalendar)
  • Data (or data elements) you may want the browser to do something with internally (XFN, rel-tag, rel-license XOXO)
  • Data that isn't helpful to a user, but directed more at spiders or other consuming applications (hresume or hreview in whole parts, no-follow)

What I think is essential at this state in planning the Camino support for Microformats is the following:

  • Deciding what formats to support
  • Nailing detection of the formats chosen
  • Deciding what to do with that information (e.g. exporting a vcard vs. trying to pass calendar info directly to iCal)
  • Developing some clean UI that makes it all work without getting in the way

I think a good place to focus (as the others form the links already have) are with support for detecting and handing off hcard, hcalendar and hatom formats and looking at new UI / context menu items for enhancing the link types like rel-tag, rel-license and XFN

In the end, the process can probably take a lot from the feed discovery bits, though there will surely be some differences in UI both in selection and in handing off the item to other applications.

Another brain dump by User:Maxr

I agree with what Chris mentioned above. I'd like to hone it down a bit.

We should probably only support formats that have been approved and slowly consider supporting ones that haven't. As a starting point, I think that hCalendar and hCard are the two, most sensible formats to support.

In my mind, microformats are secondary to web browsing and shouldn't be given any premier real estate on screen. In that mind, they should exist in the status bar to start. We can potentially discuss a toolbar icon (or two?) but placing them in the status bar is the most logical thing to do to start.

My proposal is to implement hCalendar and hCard for Camino 2.0 is as follows:

  • Create a parser for hCalender and hCard
  • Create two icons: one for hCalendar, one for hCard
  • Show an icon each in the status bar when either hCalendar or hCard are on the page (this potentially means two new icons in the status bar)
  • When clicking on the icons, show a mini-menu which lists all available microformats (for example, there might be two hCards on the page, which will get listed in this menu)
  • Clicking on an item in the menu will send off the item to the default viewer/reader for it. Example: Clicking an hCalendar will load up iCal (assuming it's the default handler) and add the event to it. There might be some conversion magic that happens here to convert the hCard/hCalendar to a format other apps can recognize. hCards will become vCards for example.
  •  ???
  • Profit

And there is my proposal. As I said, this is only for the first two microformats. We'll add more as they become relevant and can integrate into the browser in a meaningful way. hAtom would, arguably, be the next one to add, but we'll take it as it comes.

Thoughts? Comments?


  • I like it the basic UI design. Hwaara and I were talking about making the icons have a "glowing" icon much like the proposed IM mockup here, which could solve some of the "they're invisible on the status bar" arguments. Froodian 02:01, 1 August 2006 (PDT)
Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox