-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How should sidebarAction
be considered, since it’s only implemented in two browsers?
#21
Comments
My first impression is that it probably makes sense for the specification effort to approach this as an optional module that individual vendors may choose to adopt. I think existing implementations may provide enough reference material to begin drafting a spec for this namespace, but we may not have enough input from implementers to include it a report (a formal document published by the group). |
Let me just comment that a feature having two publicly shipped interoperable implementations will pass Candidate Recommendation's exit criteria and then qualifies for standardization... |
Naver Whale also implemented sidebar_action. Tho it's using a different syntax. For example, it requires the use of default_page instead of default_panel. Even tho it tolerates the syntax of Opera and Firefox. Unlike those two browsers, it can't run alongside other action declarations (action, browser_action, page_action). See: https://developers.whale.naver.com/api/extensions/sidebarAction/ |
Agreed that we should not specify vendor-specific APIs in order to keep the main specification focused on cross-browser compatibility. Such capabilities may be added to the spec in the future if there's sufficient interest from other browsers. |
Unifying some form of sidebar api is tracked here: |
Both Firefox and Opera implements a mostly non-overlapping API under the sidebarAction namespace (agreeing on the
sidebar_action
key of themanifest.json
).Considering that most browsers don’t implement it, should this be described somehow, and considered part of the main spec while being optional, or an extension of it? Is two implementors sufficient to be considered something we want to describe, for interoperability purposes? Anyway, I guess it could be good to have guidelines for vendor-specific extensions of the WebExtensions API so that the whole stays coherent (and fit for a potential later standardization).
The text was updated successfully, but these errors were encountered: