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.
- Jon Hicks blog post on safari plugin ui proposal
- Tails Firefox extension
- Microformats.org wiki UI discussion -- collection of links to other implementations and discussions
- Thread on firefox support from mozilla.dev.planning
- Digital Web Magazine "The Big Picture on Microformats"
- Jon Hicks, Highlight Microformats with CSS - a sample user style sheet modification for showing microformat content in pages
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.
- Robots Exclusion
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.
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.