[whatwg] HTML extension for system idle detection.

On Sun, Sep 13, 2009 at 12:08 PM, Jens Alfke <snej at google.com> wrote:
> That is not what "idle" means to an instant-messaging/presence service like
> AIM or Jabber. The "idle" state means the user is not at the device, to the
> best of its knowledge. If the user is capable of receiving messages but does
> not want to be interrupted, that's called "away" or "busy". If the user is
> not able to receive messages at all, s/he's effectively offline.
>
> Given that we are designing this API primarily for the benefit of IM apps,
> we need to end up with something that matches their semantics.

It's only useful for IM apps to know that the user is present but not
paying attention to them because they typically have the ability to
obtain the user's attention somehow -- e.g., by popping up a window or
causing something on the task bar to flash.  As far as I know, web
apps have no way to get the user's attention if they aren't using the
web app, do they?  I'd imagine popping up a window isn't reliable --
it might be stopped by a popup blocker, or the user might have all new
windows going to tabs, or something like that.  (Is there a new API
for that, perhaps?)

> I'm fine with those statements as long as you append "...on our specific
> platform" to each one. In the general case, however, especially on
> non-mobile platforms, they aren't true at all. In particular, the solution
> you describe is absolutely not a solution to the problem under discussion
> here, for any general purpose OS, because it does not match the
> long-established semantics of "idle" in instant-messaging/presence
> protocols, i.e. no detectable user interaction with the computer as a whole.

I agree with this.  If some platforms don't let applications run in
the background, I don't see why that should prevent the creation of an
idle detection API.  It just wouldn't really work on those platforms,
like a lot of other web app functionality (like checking for new mail
in the background).  The WHATWG is mainly trying to support rich
applications for desktops or near-desktops, not a
lowest-common-denominator feature set that will work even on minimal
devices.

Received on Sunday, 13 September 2009 09:51:54 UTC