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

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

From: Anne van Kesteren <annevk@opera.com>
Date: Wed, 31 Aug 2011 17:28:27 +0200
To: "Robin Berjon" <robin.berjon@gmail.com>, "Anssi Kostiainen" <anssi.kostiainen@nokia.com>
Cc: "public-device-apis@w3.org WG" <public-device-apis@w3.org>
Message-ID: <op.v023xpm564w2qv@annevk-macbookpro.local>
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?

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 van Kesteren
Received on Wednesday, 31 August 2011 15:29:08 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:50 UTC