canmove, Confirmed users
901
edits
ExposureGuidelines: Difference between revisions
Incorporate some feedback from Marcos Caceres on Firefox OS section
m (Clarify what "lack of feedback" doesn't stop) |
(Incorporate some feedback from Marcos Caceres on Firefox OS section) |
||
| Line 24: | Line 24: | ||
Mozilla seeks feedback from other browser engines during development and implementation of web APIs. Lack of feedback will not stop our implementation as it may simply indicate lack of interest at that time from another browser engine. We will attempt to reciprocate this feedback to other browser engines when they are developing a feature or API that we believe to/will be relevant, even if we won't implement it ourselves in the short term. | Mozilla seeks feedback from other browser engines during development and implementation of web APIs. Lack of feedback will not stop our implementation as it may simply indicate lack of interest at that time from another browser engine. We will attempt to reciprocate this feedback to other browser engines when they are developing a feature or API that we believe to/will be relevant, even if we won't implement it ourselves in the short term. | ||
=== | ===Special Cases=== | ||
New '''user-facing products like Firefox OS''' may need to ship APIs that have not yet been embraced by other browser engines or thoroughly discussed by standards bodies. Products such as Firefox OS would ship these APIs as a part of their product but not to the broader web, thus clearly indicating their lack of standardization and limiting the number of web developers relying upon them. When | New '''user-facing products like Firefox OS''' may need to ship APIs that have not yet been embraced by other browser engines or thoroughly discussed by standards bodies. This allows Mozilla to innovate at a faster pace (providing functionality not yet available on the web such as telephony or Bluetooth, for example) than would be possible through a standards organization but comes with the price of proprietary APIs. Products such as Firefox OS would ship these APIs as a part of their product but not to the broader web, thus clearly indicating their lack of standardization and limiting the number of web developers relying upon them. Mozilla learns from efforts such as Firefox OS and uses this knowledge to inform various standardization efforts. When situations like this arise, '''API standardization must begin within one year of shipping''' the initial version of such products. Our aim is to standardize our proprietary APIs so they become available on royalty free basis for the benefit of the web community at large. | ||
Since APIs will very likely change as they are standardized and some developers will build things on top of non-standardized versions of these APIs, we will try to reasonably assist affected developers where possible. Should an API's standardization process fail, it is unclear what will be done with the non-standard API that has been shipped since some people will surely be relying upon it, even if it is only a part of one product and not available to the web at large. | Since APIs will very likely change as they are standardized and some developers will build things on top of non-standardized versions of these APIs, we will try to reasonably assist affected developers where possible. Should an API's standardization process fail, it is unclear what will be done with the non-standard API that has been shipped since some people will surely be relying upon it, even if it is only a part of one product and not available to the web at large. In any case, we will not expose these APIs to the web at large. | ||
=Implementation Process= | =Implementation Process= | ||