- 1 Status
- 2 Overview
- 3 Design & Implementation
- 4 Discussion & Implications
- 5 Notes from security review
Bugs that are blocking full microformats impl
- bug 377450 - HTML parser hooks for efficient microformat parsing
Microformats in Firefox 3 are intended to provide extension developers with easy access to microformatted content on web pages. There is also the potential of prodiving user interface associated with microformats.
As the browser becomes the "information broker" for the web, it becomes much more important that semantic data like microformats be exposed through the browser.
The use case here is to have one method for retrieving and parsing microformats in the browser so that extensions can concentrate on innovating in the microformats user interface space instead of worrying about how to get and parse the data.
Each of these extensions performs the following common functions:
- Determine if there are microformats on the page
- If there are microformats, display some indicator that the microformats are there
- If the user requests, display information from the microformats (content, etc.)
- Monitor the page for DOM changes and if they happen, refresh the microformat content in the user interface.
Where the extensions differ is what the user is able to do with that data (export, actions, etc.)
So what Firefox should provide is a method to find and parse microformats.
From: Firefox 3 PRD
|CON-008a||Create document-parsing framework for detecting microformats||Michael Kaply|
|CON-008b||Create API for developers to leverage the microformat detection framework||Michael Kaply|
|CON-009c||Support hCard, hCal, and geo||Michael Kaply|
Describe the rough schedule here, linking back to relevant product release milestones, as well as linking to any build/release notes.
Design & Implementation
- Indicate where the code for the feature lives (in branch or as extension).
The only API change being investigated is a way to check if content has microformats on the page. The primary API is a new API and is documented here: Architecture
Additional microformats can be added into the Firefox space by any extension. This is documented at devmo
There are no changes to preferences or customization for this feature.
This code is not enabled until an extension chooses to access microformats, so it does not have an effect on regular performance.
Testing has been done in using the API with pages that have 100s of microformats, and there were no performance issues in the microformats code itself.
list effects on reliability/stability, tests used, metrics targeted
Security and Privacy
- What security issues do you address in your project?
- Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?
- There are no configuration files or prefs. If the Microformats.js file is missing from modules, microformats simply don't work.
- Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.
- The microformats code does not deal with "active" content. It queries the contents of DOM nodes using textContent. It does not process any JS that is contained in those DOM nodes.
There are no privacy impacts in this code.
There are no l10n requirements. There is no special accessibility requirements, since there are no browser UI changes.
Microformats in Firefox should have no effect on web compatibility.
If we publicize an interface to add microformats to Firefox, we will need to maintain some compatibility as Firefox is upgraded.
any other implementation or design related documentation
Discussion & Implications
Caveats / What We've Tried Before
links to previous design documents, discussions, etc.
Firefox/Feature Brainstorming:Microformat Handling (take this page with a grain of salt)
Notes from security review
- Test Microformats code when loaded as a resource URL on a web page (resource://gre/modules/Microformats.js)
- Determine if XPCNativeWrappers are on for Component.imports
- Turn native wrappers off in and see what happens.
- Check for native wrapper on incoming nodes
- Don't default to content.document if there is no rootElement
- Escape XPath queries
- Add a warning to recurseFrames about domains not being from the same level
- Update using microformats with a better description of the returned objects (mention node, resolvedNode, etc.)
- Check for a replacement for getBoxObjectFor in FF3
- Test with strict mode on.
- Document that URLs are not sanitized.