On Thu, Aug 25, 2011 at 3:23 PM, Ian Hickson i...@hixie.ch wrote:
Will the methods above adequately handle this?
I believe from Gmail's perspective, yes.
Notifications shouldn't require any clicks at all. They should just work,
initially constrained to the browser page, with an
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.
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
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.
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
I definitely have privacy concerns regarding a isRegistered function.
Such a function might be ok in some contexts, but I'd like to avoid it
as far as possible.
For example I don't think we need to think in terms of the, arguably
crappy, UI that browsers currently use. One simple improvement that
If offering a potentially registerable api is done via
link rel=protocol-handler type=foopy: href=...
Then it'd be reasonable for a handling page to return some well known
HTTP response (410?) to indicate that the API is no longer supported.
The site wouldn't need to call a method, and the user
On Fri, Jul 8, 2011 at 12:05 AM, Jonas Sicking jo...@sicking.cc wrote:
I definitely have privacy concerns regarding a isRegistered function.
Such a function might be ok in some contexts, but I'd like to avoid it
as far as possible.
Just to be clear, you have privacy concerns for an
On Fri, Jul 8, 2011 at 9:44 AM, Ojan Vafai o...@chromium.org wrote:
On Fri, Jul 8, 2011 at 12:05 AM, Jonas Sicking jo...@sicking.cc wrote:
I definitely have privacy concerns regarding a isRegistered function.
Such a function might be ok in some contexts, but I'd like to avoid it
as far as
On 07/06/2011 07:51 AM, Robert O'Callahan wrote:
I don't think browsers need to prompt for registerProtocolHandler. Instead,
I would simply allow any site to register as a protocol handler for almost
anything, and remember all such registration
So all the ad sites (which are embedded via
On Thu, Jul 7, 2011 at 6:41 AM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 07/06/2011 07:51 AM, Robert O'Callahan wrote:
I don't think browsers need to prompt for registerProtocolHandler.
Instead,
I would simply allow any site to register as a protocol handler for almost
anything, and
On Thu, Jul 7, 2011 at 12:53 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Thu, Jul 7, 2011 at 6:41 AM, Olli Pettay olli.pet...@helsinki.fiwrote:
On 07/06/2011 07:51 AM, Robert O'Callahan wrote:
I don't think browsers need to prompt for registerProtocolHandler.
Instead,
I would
Olli Pettay wrote:
On 07/06/2011 07:51 AM, Robert O'Callahan wrote:
I don't think browsers need to prompt for registerProtocolHandler.
Instead,
I would simply allow any site to register as a protocol handler for
almost
anything, and remember all such registration
So all the ad sites (which
All the arguments for registering handlers aside, it ought to be possible
for a website to provide some UI for deregistering. For example, many users
will expect to go into gmail's settings to stop having gmail handle email
links. Gmail's help section needing to give users instructions on each
Peter Kasting wrote:
On Fri, Jul 1, 2011 at 1:59 PM, Ojan Vafaio...@chromium.org wrote:
Do any browser vendors agree with this or have objections?
From my work on the Chrome UI side of this, I would very much like to see
something like isRegistered(). This would allow sites to
Rich Tibbett wrote:
Peter Kasting wrote:
On Fri, Jul 1, 2011 at 1:59 PM, Ojan Vafaio...@chromium.org wrote:
Do any browser vendors agree with this or have objections?
From my work on the Chrome UI side of this, I would very much like to
see
something like isRegistered(). This would allow
On Tue, 05 Jul 2011 00:41:13 +0200, Peter Kasting pkast...@google.com
wrote:
In general, I echo Michael's comment that we follow the notifications
model.
That means using http://dev.w3.org/2009/dap/perms/FeaturePermissions.html
I take it? I am still somewhat dubious about that idea given
For rPH, please don't require a user-initiated click for the call. That's
one very annoying thing about notifications - it takes users two clicks to
enable them, and every app has to find some suitable in-page UI to ask users
to make the first click. Since both notifications and rPH are confirmed
On 7/5/11 3:58 PM, Michael Davidson wrote:
Prompting for permissions is much less annoying than opening a new window
That's unclear. Especially if permission grants are persistent.
so I don't think the same standards should apply.
If anything, persistent permission grants should have a
On Tue, Jul 5, 2011 at 1:14 PM, Boris Zbarsky bzbar...@mit.edu wrote:
so I don't think the same standards should apply.
If anything, persistent permission grants should have a _higher_ bar than
opening a temporary pop-up window...
Granting permission, yes. But just asking for permission?
On 7/5/11 4:48 PM, Michael Davidson wrote:
Granting permission, yes. But just asking for permission?
If the asking for permission can happen in a context in which the user
can't tell what's being asked for, it's a really bad idea...
I say it's less annoying because (in Chrome, anyway), the
On Tue, Jul 5, 2011 at 2:00 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 7/5/11 4:48 PM, Michael Davidson wrote:
Granting permission, yes. But just asking for permission?
If the asking for permission can happen in a context in which the user
can't tell what's being asked for, it's a really
On 7/5/11 5:04 PM, Michael Davidson wrote:
If the asking for permission can happen in a context in which the
user can't tell what's being asked for, it's a really bad idea...
Can you clarify what you mean? Requiring an in-page click doesn't mean
that the user understands either.
On Tue, Jul 5, 2011 at 2:12 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Yes, I'm not saying in-page click is a solution. It works for popups, sort
of, but I don't think it does for permission request notifications.
To be truly honest, requiring a user gesture probably doesn't work for rPH()
I don't think browsers need to prompt for registerProtocolHandler. Instead,
I would simply allow any site to register as a protocol handler for almost
anything, and remember all such registrations. When the user navigates to a
URI whose protocol has had an app newly registered for it since the
In general, I echo Michael's comment that we follow the notifications model.
On Sun, Jul 3, 2011 at 1:01 PM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
Right now sites are actually much _more_ annoying without this
feature as they just blindly ask you to make them your
Or we could use a link and have the UA only show the option to the
user if it feels like it. The UA could choose not to show it if it's
already active. It could also choose to only show it if the user has
visited repeatedly or whatever.
This is closer to ATOM discovery, but it's also a deployed
On 7/1/11, Ojan Vafai o...@chromium.org wrote:
Do any browser vendors agree with this or have objections?
I don't look forward to being blackmailed by sites into me allowing
them to register for X or else I don't get their content.
I have a bank which won't let me bank unless I have Java
On Sun, Jul 3, 2011 at 12:11 AM, timeless timel...@gmail.com wrote:
It isn't ok to say You can't do X unless you make Y your default Z.
I would prefer to solve this if it actually becomes a problem. Right now
sites are actually much _more_ annoying without this feature as they just
blindly
Peter Kasting pkast...@google.com schrieb am Sun, 3 Jul 2011 12:24:17
-0700:
On Sun, Jul 3, 2011 at 12:11 AM, timeless timel...@gmail.com wrote:
It isn't ok to say You can't do X unless you make Y your default
Z.
I would prefer to solve this if it actually becomes a problem.
Without
Has anyone seen a site that refuses to work unless notifications are active?
I suggest that we follow the notification model since it seems to work well
for both site authors and users.
I imagine that if sites force users to accept notifications or protocol
handlers, those sites won't have many
Do any browser vendors agree with this or have objections? Hixie, this seem
OK to you?
These additions seem safe, simple and enable sites giving users a better
experience.
On Wed, Apr 20, 2011 at 11:32 PM, James Kozianski k...@chromium.org wrote:
Hi,
I'd like to propose the following changes
On Fri, Jul 1, 2011 at 1:59 PM, Ojan Vafai o...@chromium.org wrote:
Do any browser vendors agree with this or have objections?
From my work on the Chrome UI side of this, I would very much like to see
something like isRegistered(). This would allow sites to conditionalize
requests for the
From my perspective on Gmail, I would prefer to know if the user hasn't
registered because they declined previously or haven't been asked. If
they've declined previously, then calling registerProtocolHandler() in
today's UAs will not do anything. If I can't detect that state, then they'll
keep
Agree. This seems strictly superior. Just to bikeshed on the name a bit,
since this is hanging off the navigator object, the name should probably
mention something about protocols, protocolState()?
On Fri, Jul 1, 2011 at 2:25 PM, Michael Davidson m...@google.com wrote:
From my perspective on
On 07/02/2011 12:25 AM, Michael Davidson wrote:
From my perspective on Gmail, I would prefer to know if the user hasn't
registered because they declined previously or haven't been asked. If
they've declined previously, then calling registerProtocolHandler() in
today's UAs will not do anything.
On Fri, Jul 1, 2011 at 2:58 PM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 07/02/2011 12:25 AM, Michael Davidson wrote:
From my perspective on Gmail, I would prefer to know if the user hasn't
registered because they declined previously or haven't been asked. If
they've declined
On Fri, Jul 1, 2011 at 3:03 PM, Ojan Vafai o...@chromium.org wrote:
I'm not sure what the privacy issue here is given that we restrict to
same-domain. You're already using the site, so it's just whether they can
tell that you use them as a protocol handler. I don't see a problem with
exposing
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
39 matches
Mail list logo
