W3C home > Mailing lists > Public > public-device-apis@w3.org > September 2011

Re: [battery] addEventListener side effects, ordering & boundary crossing of battery{low, critical}, window.on*

From: Anssi Kostiainen <anssi.kostiainen@nokia.com>
Date: Thu, 1 Sep 2011 15:19:30 +0300
Message-Id: <2157F872-62E3-4292-B281-DE15DA66A2E3@nokia.com>
To: "public-device-apis@w3.org WG" <public-device-apis@w3.org>, ext Anne van Kesteren <annevk@opera.com>
Hi Anne, All,

On 31.8.2011, at 18.28, ext Anne van Kesteren wrote:

> On Wed, 31 Aug 2011 15:20:55 +0200, Anssi Kostiainen <anssi.kostiainen@nokia.com> wrote:
>> On 31.8.2011, at 14.31, ext Anne van Kesteren wrote:
>>> Modifying how addEventListener() works violates DOM Core. Not really acceptable.
>> 
>> Do you have an alternative design in mind that would address the above use case in a DOM Core conformant manner?
> 
> http://lists.w3.org/Archives/Public/public-geolocation/2011Jul/0023.html has an alternative.
> 
>>> I think initBatteryStatusEvent() should be dropped. New specifications should use the DOM Core event constructor mechanism and not further proliferate init*Event() methods.
>> 
>> The new constructor is really great, but I think supporting both the old and the new model simultaneously would be a relatively small investment considering you'd get better compatibility with legacy content, e.g. in JavaScript convenience libraries. Or WDYT?
> 
> There is legacy content for initBatteryStatusEvent()? Given that this specification thus far does not have wide adoption in browsers I think it can still be safely dropped. You can use http://www.w3.org/TR/progress-events/ as an example.

Anne - Thanks for the pointers.

Here's my initial take on an alternative Battery Status Events design which tries to address Anne's concerns. The design borrows ideas and concepts from DOM Core and Progress Events (BatteryStatusEvent() constructor), Channel Messaging (start(), stop()) and Server-Sent Events (BatteryStatusEventSource interface). The proposal is likely to contain glaring bugs, so beware (and feel free to fix them, or propose a better design):

[Constructor]
interface BatteryStatusEventSource : EventTarget {
  attribute Function? onbatterystatus;
  attribute Function? onbatterylow;
  attribute Function? onbatterycritical;
  attribute Function? onbatteryok;
  void start();
  void stop(); // or close()?
};

[Constructor(DOMString type, optional BatteryStatusEventInit eventInitDict)]
interface BatteryStatusEvent : Event {
  readonly attribute boolean isPlugged;
  readonly attribute float? level;
  readonly attribute DOMString? status;
};

dictionary BatteryStatusEventInit : EventInit {
  boolean isPlugged;
  float? level;
  DOMString? status;
};

The interfaces could be also renamed to BatteryEventSource, BatteryEvent and BatteryEventInit for brevity. BatteryStatusEventSource could be also called something totally different.

The onbattery{status|low|critical|ok} event handlers, and their corresponding event handler event types battery{status|low|critical|ok} must be supported as IDL attributes by all objects implementing the BatteryStatusEventSource interface.

The first time a BatteryStatusEventSource object's onbattery{status|low|critical|ok} IDL attribute is set, the BatteryStatusEventSource's task source must be enabled, as if the start() method had been called.

Some examples using the alternative design:

// 1) use addEventListener(), must call start()

var battery = (new BatteryStatusEventSource()).start();

battery.addEventListener('batterystatus', function (e) {
  console.log(e.status);
}, false);

// 2) use onbatterystatus, no need to call start()

var battery = new BatteryStatusEventSource();

battery.onbatterystatus = function (e) {
  console.log(e.status);
};

All - Would you like the working group to make progress based on this alternative proposal instead of the current Editor's Draft? Any comments, bug fixes etc. are welcome.

-Anssi

(Tracker, this relates to ISSUE-113 and ACTION-448.)
Received on Thursday, 1 September 2011 12:20:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:22 GMT