- From: Andrei Popescu <andreip@google.com>
- Date: Tue, 22 Feb 2011 14:30:19 +0000
- To: Anne van Kesteren <annevk@opera.com>
- Cc: Dean Jackson <dino@apple.com>, Steve Block <steveblock@google.com>, public-geolocation@w3.org
On Tue, Feb 22, 2011 at 8:56 AM, Anne van Kesteren <annevk@opera.com> wrote: > On Tue, 22 Feb 2011 02:11:59 +0100, Dean Jackson <dino@apple.com> wrote: >> >> On Feb 21, 2011, at 5:52 AM, Andrei Popescu wrote: >>>> >>>> Without the system UI, we're requiring: >>>> >>>> - users to know how to calibrate their compass >>>> - web developers to know how to explain to the every user calibration >>>> for every device type. >>>> >>>> I really doubt that is possible. >>> >>> Yeah, I see what you are saying...but we've seen quite a few cases >>> where developers are not that happy with the browser popping up random >>> UI (e.g. quota dialogs for storage APIs, etc). They'd much rather like >>> to have full control over the experience the users have when using >>> their application, so perhaps we should try to do away with system UIs >>> whenever possible? >> >> I agree that's a good goal. I wasn't strictly arguing against the >> properties in my previous email - just pointing out that I'd prefer it to be >> a system dialog. If a Web developer manages to confuse their user by giving >> a message to shake their phone in the wrong way, then that's their problem >> :) > > I'm not sure if this works here but typically this is addressed by a > cancelable event. E.g. for form validation, application cache, etc. When not > canceled the system dialog will appear. > I think this is a good idea, although we'd have to add a separate 'CompassNeedsCalibration' event, right? The system UI would then only appear if the app hasn't called preventDefault(). This might work, although I am not sure when we would fire such an event... Andrei
Received on Tuesday, 22 February 2011 14:30:54 UTC