WebExtensions/FAQ: Difference between revisions

WebExtensions/FAQ (view source)

Revision as of 23:25, 24 August 2015

379 bytes removed , 24 August 2015

editing

Wmccloskey

Confirmed users

130

edits

@@ Line 1: / Line 1: @@
-=== It sounds like you're copying Google.... ===
+=== It sounds like you're copying Google... ===
-The Chrome extension API was designed to work well with process separation and we are certainly taking inspiration from it and copying functionality where it makes sense. In other areas it doesn't.
+The Chrome extension API was designed to work well with process separation and we are certainly taking inspiration from it and copying functionality where it makes sense. However, there will be differences. We won't implement all of Chrome's APIs, and we will implement our own APIs. Imagine the APIs as a Venn diagram. In the middle are cross-browser APIs for content scripts, tabs, and windows. In the Firefox side are APIs for toolbars and sidebars. On the Chrome side are APIs for Google's cloud services.
-=== How will the WebExtensions API be different from the Chrome Extension API===
-You could imagine a Venn Diagram of the two extension APIs. One circle is Chrome's, the other WebExtensions. The overlapping are are basic extension functionality (''give some examples'').
-Outside of that overlap area would be the areas of differentiation. For example, we don't have much interest in providing easy access to Google's services though WebExtensions. We do however want to support certain use cases that don't seem to be a priority for Google. We have identified a few such areas that we want to support such as ad-blocking, tab management, UI modification and time/location shifting content.
+=== How will WebExtensions be cross-browser if you're extending Google's API? ===
+Unlike the web platform, we don't expect every browser to implement every aspect of WebExtensions in the same way. Hopefully there will be APIs that all browsers agree on, and they will work essentially the same way in all browsers. But there will also be APIs that are more browser-specific. For example, it's unlikely that Chrome will ever support a toolbar API, but Firefox probably will.
+Even without perfect compatibility between browsers, a common API still has many advantages for extension developers. If developers stay within the common API, their extensions will automatically work across browsers. Even if developers choose to use browser-specific APIs, their extensions may be usable on other browsers through feature detection and fallbacks. For example, an extension using a toolbar API might be able to fall back to the browser action API on other browsers.
 === Why WebExtensions and not Jetpack? ===
@@ Line 13: / Line 15: @@
 Finally, Jetpack doesn't solve the problem that add-on developers must code for two very different APIs. Basing WebExtensions off Chrome's API means that developers who stick to the common APIs will only have to maintain one codebase.
-=== How will WebExtensions be cross-browser if you're extending Google's API? ===
-Unlike the web platform, we don't expect every browser to implement every aspect of WebExtensions in the same way. Hopefully there will be APIs that all browsers agree on, and they will work essentially the same way in all browsers. But there will also be APIs that are more browser-specific. For example, it's unlikely that Chrome will ever support a toolbar API, but Firefox probably will.
-Even without perfect compatibility between browsers, a common API still has many advantages for extension developers. If developers stay within the common API, their extensions will automatically work across browsers. Even if developers choose to use browser-specific APIs, their extensions may be usable on other browsers through feature detection and fallbacks. For example, an extension using a toolbar API might be able to fall back to the browser action API on other browsers.
 === Which add-ons will stop working after the deprecation? ===