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

Hi Anne, Robin,

Thanks for your feedback and contributions.

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

> On Wed, 31 Aug 2011 13:21:55 +0200, Robin Berjon <robin.berjon@gmail.com> wrote:
>> On Aug 18, 2011, at 13:54 , Anssi Kostiainen wrote:
>>> * ISSUE-113: AddEventListener in Battery Status has side effects
>>> 
>>> The discussion on public-geolocation on the same issue was inconclusive:
>>> 
>>> http://lists.w3.org/Archives/Public/public-geolocation/2011Jul/0009.html
>>> 
>>> It seems there's a tradeoff between consistency, performance, ease of use (for developers), and architectural purity with any of the available alternatives. The current design is arguably fairly consistent, shouldn't have performance pitfalls, and should be easy for developers. Thus I'd propose to leave it as is in the spirit of:
>>> 
>>> http://www.w3.org/TR/html-design-principles/#priority-of-constituencies
>>> 
>>> (If we would simply remove the requirement "When an event listener is registered with the event type batterystatus, then the user agent must ..." e.g. a battery monitor use case could not be implemented consistently. You'd get the status only after isPlugged changes its value or level changes by 1%. In the worst case, where the isPlugged is true and the battery is at 100%, you would not get *any* battery status information until the device is unplugged. To alleviate that the level threshold could be changed, but that'd compromise the performance.
>> 
>> Definitely +1 on this resolution.
> 
> 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?

>> It all looks really good to me. I've taken the liberty of making a few small editorial changes to the documents, mostly because fixing the typos was faster than reporting them. I did make one substantive change which I think we should discuss. In filling out the descriptions for the parameters of initBatteryStatusEvent(), I have:
>> 
>>  a) added a requirement to properly constrain the values of level in case the author passes -17 or 42389;
>>  b) been wondering if it should be possible to pass true for cancelable and bubbles given that the event types are normally neither (at this point I've left them open).
>> 
>> Thanks a lot, this looks to be in good shape.
> 
> 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?

-Anssi

Received on Wednesday, 31 August 2011 13:21:51 UTC