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

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.


> I'd feel more comfortable staying where we are on this for now, unless  
> we get implementer feedback to the contrary. The upcoming new Event()  
> syntax should IMHO further alleviate the need for on* handlers.

They are orthogonal. Event handlers are a convenient way to listen for an  
event whereas new Event() is a convenient way to create an event.


> 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.


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Wednesday, 31 August 2011 11:32:00 UTC