Re: [whatwg] Proposal to extend registerProtocolHandler
On Tue, Aug 2, 2011 at 5:53 AM, Ian Hickson i...@hixie.ch wrote:
On Tue, 26 Jul 2011, James Kozianski wrote:
Here are the use cases I had in mind:
1. Allow sites to conditionally show UI to promote the advantages of
registering the site as a handler.
(requires isRegistered)
2. Allow sites to provide settings screens which allow users to register
/ deregister handlers from within the site.
(requires isRegistered, and deregisterProtocolHandler)
The presence of an ignored list - sites who don't have permission to use
registerProtocolHandler - necessitates Michael Davidson's suggestion
that isRegistered() should return a tri-state value (REGISTERED,
DECLINED, NOTASKED). Otherwise sites that have been 'ignored' by a user
won't be able to tell if they should show their promotional UI or not.
Could you elaborate on what kind of UI we'retrying to enable here?
Based on the above use cases, it seems the API that directly addresses
them is:
navigator.shouldShowHandlerPromo('mailto:') = true/false
navigator.getCurrentHandlerState('mailto:') =
'display UI to unregister'
'display UI to register'
'tell user browser-specific way to re-enable previously declined
registration' (?)
navigator.unregisterHandler('mailto:')
...and equivalent for MIME types. Is that really all that is needed here?
(Ignore the names of the methods, they're not the names I'd use.)
shouldShowHandlerPromo() seems to capture the intent of the isRegistered()
function quite well. I can't think of any valid use cases apart from showing
promotional UI. A concrete example of the kind of UI we're trying to enable
is gmail's notifications UI [1].
getCurrentHandlerState() also seems to be fine. The intended result is that
a web developer can have something like a settings page that lets users
modify their protocol handler settings for that site, eg a form with radio
buttons for enable / disable. Again, gmail has an example of the UI we'd
like to enable [2].
Cheers,
James
[1]
http://t1.gstatic.com/images?q=tbn:ANd9GcSqpKN5FmbWKiC-6e-ptj6KJ_qbiyPuPj2M1YZO2wwIOAf6qdX8
[2]
http://img.technified.net/tf/Gmail-Desktop-notifications-for_14988/gmail-desktop-notification-settings.png
Re: [whatwg] Proposal to extend registerProtocolHandler
Hi Ian, Here are the use cases I had in mind: 1. Allow sites to conditionally show UI to promote the advantages of registering the site as a handler. (requires isRegistered) 2. Allow sites to provide settings screens which allow users to register / deregister handlers from within the site. (requires isRegistered, and deregisterProtocolHandler) The presence of an ignored list - sites who don't have permission to use registerProtocolHandler - necessitates Michael Davidson's suggestion that isRegistered() should return a tri-state value (REGISTERED, DECLINED, NOTASKED). Otherwise sites that have been 'ignored' by a user won't be able to tell if they should show their promotional UI or not. Cheers, James On Sat, Jul 23, 2011 at 8:33 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 21 Apr 2011, James Kozianski wrote: I'd like to propose the following changes to the registerProtocolHandler spec. [...] Before I study the proposals in detail, is there a description of the kind of experience we're trying to enable here? What are the UIs we expect to see page use wih registerProtocolHandler()? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Proposal to extend registerProtocolHandler
Hi, I'd like to propose the following changes to the registerProtocolHandler spec. 1. Introduce an isRegistered() function. Currently if a site wants its users to register it as a handler for a given protocol it has two options: a) It can call registerProtocolHandler() on page load. (This approach was suggested in [1]) b) It can have a button that the user clicks (or similar) to enact the registration. The former is problematic because the call to registerProtocolHandler will cause the browser's UI to notify them of the registration (or prompt them to make a decision), which is redundant if it occurs on every page load. The latter is problematic because it puts the onus on each site developer to provide the UI to allow the user to make the change. Also, as the site doesn't know whether the user has already registered the given protocol handler, it can't tailor its UI to reflect this. This means the UI either always shows, or never shows, both of which are undesirable. Having an isRegistered() function would allow a site to simply make the RPH call conditionally on load, or to provide a UI for it that reflects the user's current preference. 2. Introduce an unregisterProtocolHandler() function. Such a function is desirable because it allows sites to remove outdated handlers from clients and would enable clients to provide a UI for managing their registered protocol handlers. 3. Require all URL arguments to have the same origin as the page executing the call. This would would make the behaviour of this set of functions more consistent (isRegistered() should only work for same-domain queries, to prevent information leaking). Cheers, James [1] - http://www.mail-archive.com/whatwg@lists.whatwg.org/msg14548.html
