W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2014

Re: [whatwg] Preventing wake lock leaks with DOM nodes

From: Elliott Sprehn <esprehn@chromium.org>
Date: Wed, 17 Sep 2014 14:22:50 -0700
Message-ID: <CAO9Q3iJyto6CFcuVBwH3kZsFe-C=1WX+Q0FPQz-rKOMPW-WeTQ@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: WHAT Working Group <whatwg@lists.whatwg.org>, Marcos Caceres <w3c@marcosc.com>
This is what the attached and detached callbacks are for on custom
elements. Someone can build an <app-screenlock> element that requests the
lock when it's attached (added to the viewed document) and releases when
it's detached (removed from the viewed document).

There's no reason to complicate this API, developers have the primitives to
do this already.


On Mon, Aug 18, 2014 at 6:20 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Mon, Aug 18, 2014 at 5:35 PM, Marcos Caceres <w3c@marcosc.com> wrote:
> > The reason I didn't make it a boolean was because of the IPC involved
> and because I wanted to support multiple types of locks without needing to
> add new attributes in the future (and if we need to add the complex stuff
> later).
>
> What's the problem with adding more attributes in the future?
>
> That said, I do think that a "timeout" for screen locks make sense, so
> a boolean wouldn't work. Though not as a timeout for when to release
> the lock, but rather as a "minimum time I'd like to keep the screen
> awake" as described at
>
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-August/297423.html
>
> / Jonas
>
Received on Wednesday, 17 September 2014 21:24:00 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:30 UTC