canmove, Confirmed users
901
edits
ExposureGuidelines: Difference between revisions
no edit summary
(Created page with "=Goal= Mozilla aims to advance the state of the open web with new features, enhanced security, and the removal of unnecessary cruft. We will not hurt the web by exposing an A...") |
No edit summary |
||
| Line 1: | Line 1: | ||
=Goal= | =Goal= | ||
Mozilla aims to advance the state of the open web with new features, enhanced security, and the removal of unnecessary cruft. We will not hurt the web by exposing an API in such a way that a web developer can detect it before it's ready. In the past we have shipped APIs with "moz" prefixes to indicate their lack of standardization but we will no longer do this. Note that at this time, we are specifically focusing on JS APIs and not on other web-facing properties (ex. CSS). | Mozilla aims to advance the state of the open web with new features, enhanced security, and the removal of unnecessary cruft. We will not hurt the web by exposing an API in such a way that a web developer can detect it ([https://groups.google.com/a/chromium.org/d/msg/chromium-dev/HN2e4sGbVus/OIEWgN1yi04J 1]) before it's ready. In the past we have shipped APIs with "moz" prefixes to indicate their lack of standardization but we will no longer do this. Note that at this time, we are specifically focusing on JS APIs and not on other web-facing properties (ex. CSS). | ||
=Process Overview= | =Process Overview= | ||
| Line 12: | Line 12: | ||
=Declaring Intent= | =Declaring Intent= | ||
Developers of new APIs intended to be exposed to the web at large via Mozilla products must send an email to dev-platform and dev-webapi declaring their intent to implement this API. This email must have a subject line that begins with "Intent to implement:" and whose body describes the feature and links to relevant documentation. It must also demonstrate that an API is standardized as [[ | Developers of new APIs intended to be exposed to the web at large via Mozilla products must send an email to dev-platform and dev-webapi declaring their intent to implement this API. This email must have a subject line that begins with "Intent to implement:" and whose body describes the feature and links to relevant documentation. It must also demonstrate that an API is standardized as [[Special:MyPage/APIExposurePolicy#Standardization|defined below]]. Implementors must also use this email to request API review from the Mozilla [[API review]] team. These emails must be sent ''early on'' in the process of any new API's development, especially if this work is being done as part of a standards body. This will expose the API to a larger audience which can help improve its quality and avoid APIs which are designed by domain experts but aren't "webby" or friendly to JS developers. The API review team can help with the latter concern. | ||
=API review= | =API review= | ||
| Line 46: | Line 46: | ||
=Cleanup= | =Cleanup= | ||
This policy is new and we have work to do to clean up previous divergences from it. One example is [https://developer.mozilla.org/en-US/docs/Web/API/window.navigator window.navigator]. We are committed to making the necessary changes to align Mozilla's codebases with this policy. | This policy is new and we have work to do to clean up previous divergences from it. One example is [https://developer.mozilla.org/en-US/docs/Web/API/window.navigator window.navigator]. We are committed to making the necessary changes to align Mozilla's codebases with this policy. | ||
=TODO for this policy= | |||
# should we have a joint mailing list with Blink for intent to implement/ship? | |||
# how do we keep track of progress towards standardization for in-development APIs? | |||
# how do levels of API exposure for Firefox OS apps (certified, packaged, etc.) fit into this policy? | |||
# should we enforce this by putting all WebIDL files into a new module? | |||