Experience from Web content standards probably informs the situation here...
On Wed, Jul 26, 2017 at 11:46 AM, Andrew Swan <as...@mozilla.com> wrote: > For handling cross-platform versus Firefox-specific APIs, I don't think the > right outcome is perfectly clear. Of course we should learn from how > web-exposed APIs evolved and avoid the need for the browser extensions > equivalent of jquery. On the other hand, browser extensions by their > nature work with features that are not standardized and that differ from > browser to browser. For instance, we have WebExtensions APIs for working > with containers. There's no doubt in my mind that we should have this API > but of course extensions that use it won't work in other browsers. Maybe > in this case some sort of moz- prefix would be appropriate but its not hard > to come up with murkier examples. You probably don't want to use a prefix there. What if some other browser decided to support containers? Then they'd want to implement your API and having it be prefixed is then horrible for everyone. What about the tabs API? It is > currently supported in Firefox, Chrome, Edge, and Opera. But what if one > of the non-tab-based-browser-ui projects takes off and wants to support > browser extensions? If they simply don't support the tabs API then how > should the API be named to indicate to extension developers that it isn't > universally available? > It's probably best to be pessimistic about extension developers' behaviour. In practice the tabs API, or any other API, is either universally present in the browsers they care about, or it is not. In the former case they will rely on it explicitly or implicitly (e.g. by having untested fallback code paths that don't work). In the latter case they will discover the problem and fix it. Either way naming probably doesn't help much. Developers of your putative non-tabbed browser would have to recognize the situation and decide what's best for them. If there are lots of extensions that rely on the tabs API, maybe the browser developers would have to put in some stub implementation that tries to do something sensible. One thing that might help (and maybe you already have this?) is to have the extension manifest contain a whitelist of the set of APIs the extension requires. That would allow easy filtering to determine which extensions are supported by a browser. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
