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

Re: [whatwg] Proposal: Wake Lock API

From: Nils Dagsson Moskopp <nils@dieweltistgarnichtso.net>
Date: Tue, 19 Aug 2014 17:16:08 +0200
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Message-ID: <87bnrgse6f.fsf@dieweltistgarnichtso.net>
Cc: WHAT Working Group <whatwg@lists.whatwg.org>, Mounir Lamouri <mounir@lamouri.fr>, Jonas Sicking <jonas@sicking.cc>, Marcos Caceres <w3c@marcosc.com>
"Tab Atkins Jr." <jackalmage@gmail.com> writes:

> On Sat, Aug 16, 2014 at 9:19 AM, Nils Dagsson Moskopp
> <nils@dieweltistgarnichtso.net> wrote:
>> […]
>> Seems to me a declarative solution (like CSS) might be appropriate.
>> @media screen {
>>     video:playing {
>>         wake-lock: display 15s;
>>     }
>> }
>> article.recipe:target {
>>     wake-lock: display;
>> }
> That's not a terrible idea.

Thanks. ;)

> The CSSWG is generally hesitant to put behavior-altering things in
> CSS, but some bleed-through is fine, and this can be argued as an
> aspect of appearance.

I think compared to the “will-change“ property, a “wake-lock” property
would fare well. I do wonder, however, how the concept would translate
to different display technologies – like e-ink, which does not need a
wake lock, or physical media, which decompose after some time.

> This solves the GC and locking issues (the latter by delegating state
> management to CSS, which everyone already knows to use).

It would also make it easily possible to express logic similar to “do
not power off the screen immediately after a video is playing” in UA or
even user stylesheets in a no-nonsense and clearly interoperable way.

A CSS solution could also limit abuse if it included a “max-wake-lock”

Nils Dagsson Moskopp // erlehmann
Received on Tuesday, 19 August 2014 15:16:43 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:22 UTC