- From: Andrei Popescu <andreip@google.com>
- Date: Wed, 11 Nov 2009 10:52:38 -0800
- To: ifette@google.com
- Cc: Doug Turner <dougt@dougt.org>, Robin Berjon <robin@robineko.com>, W3C Device APIs and Policy WG <public-device-apis@w3.org>
Hi Ian, 2009/11/11 Ian Fette (イアンフェッティ) <ifette@google.com>: > Doug, > I wasn't trying to imply that W3C should mandate user interface. But certain > APIs lend themselves to certain experiences. <input type="file"> would be > very different if it were instead a GetFile() call. I fully agree with you here: you give a very good reason why the security mechanisms should not be designed in isolation from the actual APIs. I just wanted to make it clear that in the Geolocation WG, we considered these aspects together and, as far as I can tell, made the right choices: Geolocation is a programatic API given its intended usage (i.e. the use cases we have for it). We have a number of applications (e.g. Google search) where it is not desirable to force the users to always have to hit a button every time their location should be used for something (e.g. annotate the search query). So something like <input type="geolocation"> would not have been a good fit, unless we changed the way the input tag works (which is not desirable, either IMHO). Having made the choice of designing Geolocation as a programatic API, we next made sure that any security mechanism built around it can lend itself to a user experience that is as unobtrusive as possible. This is one reason why we made the API fully async: to allow non-modal UI (infobar / icon in URL bar / menu option / etc). On the other hand, for something like a Contacts API, if most use cases are around the user picking a subset of his contacts and interacting with them somehow (editing / sending them a message / etc) then I could see the API being built using the <input> tag, as you suggested. However, there are issues with building a security mechanism around the <input> tag, as well (e.g. will the element be stylable, etc). > My hope is that we have > in mind at least one user experience that we would actually be comfortable > shipping that matches the API, rather than just saying "eeh, don't worry > about it, some policy layer will handle it, and if there's no policy we can > fall back to a dialog box." That is not acceptable. Yep, I feel the same way about this. Thanks, Andrei
Received on Wednesday, 11 November 2009 18:53:19 UTC