info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Not prefixing APIs exposed to Web content (was: Re: navigator.id update - FX patches in progress)
65 views
Skip to first unread message
Henri Sivonen
Jun 22, 2012, 2:21:05 PM6/22/12
to dev-pl...@lists.mozilla.org
On Fri, Jun 22, 2012 at 6:58 AM, Doug Turner <doug....@gmail.com> wrote:
> Is this something that you have discussed at the W3C? Or is this just a moz-specific API, and if so, maybe we should namespace the api until there is some other UA wanting to implement.
Even though this will start out as a single-vendor API, I think it's
better to ship it without a prefix than to use a moz prefix. If we
believe that this APIs good enough to be adopted by others, I think we
should make the naming bet accordingly. I think there's better chance
of this becoming a multi-vendor API if the next vendor who implements
the API can get interop right away without an prefix incompatibility
mess and subsequent unprefixing mess. (If the W3C ends up
standardizing something different, they can pick a different
identifier, e.g. navigator.identity.)
For reasons stated in http://hsivonen.iki.fi/vendor-prefixes/ I think
we should adopt the policy dbaron proposed (
https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.platform/itl6mtx2dxI
) for CSS for Web-exposed APIs as well with an adjustment to cover the
case of shipping unprefixed APIs without blocking Basecamp or
Kilimanjaro. (I expect a proposal that'd involve blocking K9O until
someone else implements to be untenable.)
I suggest the following adjustment: If we ship (as in shipping is a
given due to e.g. K9O) an API that no one else implements even
experimentally and we expect the API to be used in Web content
(including installable app; evangelizing the API de facto means we
expect it to be used), we should ship the API unprefixed even if no
one else has an implementation yet and we should propose the API for
standardization. (Ideally, APIs that are targeted for Web content
probably shouldn't be exposed to Web content, though I gather there
may be APIs that only Gaia-bundled apps are expected to call, but
those apps are technically installed Web apps.)
OTOH, if we aren't confident enough in an API to make the bet that the
API could be what ends up being a multi-vendor API, we probably
shouldn't ship the API for use by Web content at all in order to avoid
the grief of apps having to migrate to another API later. In
particular, shipping a prefixed API and then removing the prefixed
version of the API in a subsequent release of Gecko would be bad,
because it would break apps written by the very people who buy into
using our APIs now. On the other hand, I believe e.g. globalStorage
would not have been any less painful if it had been prefixed.
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
> Is this something that you have discussed at the W3C? Or is this just a moz-specific API, and if so, maybe we should namespace the api until there is some other UA wanting to implement.
Even though this will start out as a single-vendor API, I think it's
better to ship it without a prefix than to use a moz prefix. If we
believe that this APIs good enough to be adopted by others, I think we
should make the naming bet accordingly. I think there's better chance
of this becoming a multi-vendor API if the next vendor who implements
the API can get interop right away without an prefix incompatibility
mess and subsequent unprefixing mess. (If the W3C ends up
standardizing something different, they can pick a different
identifier, e.g. navigator.identity.)
For reasons stated in http://hsivonen.iki.fi/vendor-prefixes/ I think
we should adopt the policy dbaron proposed (
https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.platform/itl6mtx2dxI
) for CSS for Web-exposed APIs as well with an adjustment to cover the
case of shipping unprefixed APIs without blocking Basecamp or
Kilimanjaro. (I expect a proposal that'd involve blocking K9O until
someone else implements to be untenable.)
I suggest the following adjustment: If we ship (as in shipping is a
given due to e.g. K9O) an API that no one else implements even
experimentally and we expect the API to be used in Web content
(including installable app; evangelizing the API de facto means we
expect it to be used), we should ship the API unprefixed even if no
one else has an implementation yet and we should propose the API for
standardization. (Ideally, APIs that are targeted for Web content
probably shouldn't be exposed to Web content, though I gather there
may be APIs that only Gaia-bundled apps are expected to call, but
those apps are technically installed Web apps.)
OTOH, if we aren't confident enough in an API to make the bet that the
API could be what ends up being a multi-vendor API, we probably
shouldn't ship the API for use by Web content at all in order to avoid
the grief of apps having to migrate to another API later. In
particular, shipping a prefixed API and then removing the prefixed
version of the API in a subsequent release of Gecko would be bad,
because it would break apps written by the very people who buy into
using our APIs now. On the other hand, I believe e.g. globalStorage
would not have been any less painful if it had been prefixed.
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
Dave Mandelin
Nov 6, 2012, 2:11:45 PM11/6/12
to dev-pl...@lists.mozilla.org
Dave
Dave Mandelin
Nov 6, 2012, 2:11:45 PM11/6/12
to mozilla.de...@googlegroups.com, dev-pl...@lists.mozilla.org
On Friday, June 22, 2012 11:21:05 AM UTC-7, Henri Sivonen wrote:
0 new messages