User:Dmose:Fx-Docs:Microformats

From MozillaWiki
Jump to: navigation, search

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: