|
|
| (One intermediate revision by one other user not shown) |
| Line 83: |
Line 83: |
| </td></tr> | | </td></tr> |
| </table> | | </table> |
|
| |
| == Agruments against implementing Microformats as core firefox features ==
| |
|
| |
| The idea of Microformats(henceforth: MF) is great, but the implementation is awful. Awful in as much as the implementations tend to ignore the current struggle in the industry to push for correct usage of tags as having well-defined meanings. After years of 'Browser anarchy' and endless ignorance of standards, we are approaching a stage, with XHTML where everyone is playing ball.
| |
|
| |
| MFs are supposed to be XHTML based formats, the X here stands for eXtensible (i.e. able to be expanded) yet the formats simply take existing HTML tags and attributes meant for other purposes and re-define them.
| |
|
| |
| The correct implementation for XHTML compatible formats of this nature (i.e. like hCard or XOXO) would be as an XML namespace that can be loaded into an XHTML document (in the same way that MathML or SVG is) and styled by any proper XHTML browser*. Instead, these formats (ab)use current tags either, in the case of hCard, and hCalendar, by promoting the creation of SPAN soup, or, as with VoteLinks and XFN, by redefining existing attributes (such as rel and rev) which then can precipitate the changing of a tags behaviour from standard. Technically, the use of the 'class' attribute in many of the formats is not a violation of the standard. But by defining special behaviours/presentations to be attached to certain element classes that might have been defined for some other purpose, the potential for confusion amongst users and erronious behaviours/presentation of incidental data is much greater.
| |
|
| |
| (*) Few current browsers are truly XHTML compatible, and therefore having a proper, well-defined XML namespace solution is not a currently viable option. Hence why these hack-like soultions have been formulated. As interim solutions, they are not all bad. They fulfill a need in the short term. However if these 'hacks' are accepted as qualified standards, there will be an inertial barrier to adoption of newer, better standards as new technologies (such as proper XHTML support) become mainstream. Web-designers and content producers will be slow in adopting more proper solutions, and the drive for adoption of XHTML in general will be reduced.
| |
|
| |
| By keeping MF support as a plugin (or plugins), everyone will stay firmly aware that these formats are only a temporary work-around and that HTML4 dependance is something that should be avoided, not kept on purely for familiarity reasons. By keeping MF support out of the Firefox/Mozilla core, this will reduce the need for core developers to spend time on a feature that should be gotten rid of at the first technological opportunity, thus freeing them to spend more time on other areas of the Application.
| |
Latest revision as of 11:23, 24 May 2007
« Firefox/Feature Brainstorming
| Specific features |
References |
|---|
- Over-arching reference
| http://microformats.org/
|
- Data and Microformat Detection
- Detect micro-formated content or implicit/latent micro-formats such as phone numbers, FedEx tracking numbers, AIM screen names, etc.
- The detectors themselves could be plug-able, so that users may replace the default detectors or add new detectors for specific content types. Thus, research, innovation, and communities could form around creating the highest quality and most accurate content detectors. Additionally, vertically oriented detectors could be developed to recognize eBay auction numbers, bugzilla bugs, pharmaceuticals, MLS numbers for real estate, etc.
|
|
- Microformat Actions
- Allow users to easily take action on detected data elements. For example, contextual menu actions for hCards could include "add to address book," "email contact," "dial number with Skype," etc. Additionally, services such as LinkedIn or Plaxo could develop their own contextual menu add-ons to allow users to do things like add detected hCards to their accounts.
- Microformat actions could be plug-able so that users may replace the default actions or add new actions for specific content types. An open and extensible system would allow users to associate content types to their choice of desktop applications or online services, similar to how Firefox 2 handles feeds.
|
|
- Microformat Collection and Storage
- Once data elements are detected, they could then be normalized to a universal schema and added to a local data store.
- User preferences or rules engines for web content could control how information is collected and saved. For example, a rule could allow a user to do things like save detected hCards found within a particular domain, etc. Distinctions would need to be made between data that is cached or explicitly saved.
- Additionally, metadata such as timestamp, source, subject, annotations, tags, user context, etc. could also be captured, perhaps within some type of metadata index. Thus, the utility and value of collected data increases as information assets increase over time.
|
|
- Microformat Visualization
- Provide mechanisms to search, browse, and visualize micro-formatted content that has been cached or saved, similar to history and bookmarks.
- Firefox could ship with a set of default views, but developers could also create add-on views that range from simple data look-ups to data mining and analysis capabilities.
- By treating data elements as simple building blocks, visualizations could occur in ways the original content providers didn't expect. Similar to how data service providers (Yahoo!, Amazon, eBay, Google) are enabling server-side data mash-ups through defined APIs, a platform for microformat visualizations could allow for client-side mash-ups from the local data store.
|
- Piggy Bank
|
- Microformat Sharing
- Once data elements have been found within a view, there should be an easy way to share data with others.
- Since email is the most ubiquitous, scalable, and widespread communications vehicle in use, why not leverage this as an initial sharing platform? For example, a user could select individual data elements or an entire result set within a view, input an email address (perhaps from the hCard store!), and simply click a send button.
|
|
- Microformat Backup and Synchronization
- Provide mechanisms to back-up the local data store (perhaps only information that is explicitly saved), or sync these data stores across Firefox installations. Firefox could also interface with existing services such as .mac, Windows Live, Google Browser Sync, etc.
|
|
- Mozilla.org
- In the meantime, microformats could be implemented throughout mozilla.org
|
|
| General tasks |
|---|
|
n/a
|
n/a
|