User:Dmose:Fx-Docs:Microformats
Status
- Feature tracking bug
Any relevant status comments for the feature can be placed here.
Overview
Provide basic support for handling microformatted data to both developers and end-users, as appropriate.
Motivation
Much of the standardization that is used in today's web revolves around presentation of data. Microformats are a way of easily including minimalist semantic data with HTML markup. In particular, this allows for higher-level representations of things like calendar events and addressbook info to be handed off whatever application the user chooses to organize such things.
Use Cases
- User uses an invitation service (such as evite) which supplies microformatted data. Firefox notices this data and allows (offers?) to hand it off to the user's preferred calendar application.
- User visits a web page with a list of people present at a conference which includes hCards of all the attendees. Firefox easily allows one or more of these hCards to be handed off to the user's preferred addressbook application.
- A microformat specific to a small community is developed. Users in this community are directed to a website which offers to install a handler specific to this sort of content.
Requirements
| CON-008a | P2 (40) | FR | Create document-parsing framework for detecting microformats | |
| CON-008b | P2 (40) | FR | Create API for developers to leverage the detection framework | |
| CON-009a | P3 (40) | FR | Display microformats in content area | |
| CON-009b | P3 (40) | FR | Allow user to configure microformat handlers | |
| CON-009c | P3 (40) | FR | Support hCard, hCal, and geo | |
| CON-009e | P3 (40) | FR | Allow web developers to override microformat display attributes | Huh? |
Schedule
Describe the rough schedule here, linking back to relevant product release milestones, as well as linking to any build/release notes.
Design & Implementation
- Documentation
- Repository
- Indicate where the code for the feature lives (in branch or as extension).
API Changes
As Operator, Tails, etc. shows, chrome implementation of microformat handling is possible today. After discussion with sayre, bsmedberg, mkaply, mrbkap and others in IRC, it sounds like there is one API that could be added to make it so that this handling doesn't create unnecessary performance loss. Specifically, there should be a way to register a set of hints to the parser that you're interested in microformats that are defined in specific ways (e.g. are delimited by 'class="hCalendar"') along with a callback. Then, if the parser detects any of the microformats that you were interested in, it'll call your callback, where you can use normal DOM methods (e.g. getElementsByClassName) to parse the content. This avoids having one or more extra tree traversals for pages which contain no microformatted content.
The "allow web developers to override microformat display attributes" doesn't really make sense to me, since the website is the one that's giving you HTML/CSS presentation with the data in the first place. Otherwise I'd think it wanted some sort of API change as well.
Extensibility
See the _API Changes_ section.
Customization
UI and preference storage for managing and using user-configured microformat handlers will be necessary.
Performance
In theory, the effect on Tp should be very tiny on pages that contain no microformat data; it's conceivable (though not terribly likely) that if an exceedingly large number of callbacks are registered that might not be true. Effect on pages that do have microformatted content will depend on the callbacks used by the specific handlers in question. We should certainly profile any handlers that we ship by default.
Reliability/Stability
None anticipated.
Security
Microformat handoff as well as any ability to allow websites to register microformat handlers will likely warrant security review.
Privacy
list privacy impacts and any tie-ins to user privacy features
Global Audience
list l10n requirements and a11y efforts
Web Compatibility
We may want to consider standardizing any API changes visible to web-content as we make them (presumably with WHATWG). Given the difficulty of predicative API design, however, that may be premature.
Upgrade/Downgrade/Sidegrade
Upgrade paths may be interesting if the APIs change after they first ship. Downgrades to revs that don't understand microformats shouldn't have any consequence other than not seeing microformatted data. What's a sidegrade?
Other
Various UI exploration has been done in Alex's Blog.
Discussion & Implications
Several m.d.a.firefox discussions
Caveats / What We've Tried Before
links to previous design documents, discussions, etc.
References
Existing extension-based implementations include:
