Re: Battery Status API Last Call Feedback

On Wed, 30 Nov 2011 06:37:33 +0100, Sergiu Dumitriu  
<> wrote:
>> The events need to be queued using the task queue defined in HTML5. It
>> should probably be worded in such a way that the attribute is updated  
>> and the event is dispatched in the same task so nothing else can  
>> observe the
>> attribute having changed before the event is dispatched.
> Is this really needed? Normally, battery events should be rare, so the  
> task queue should hold at most one event most of the time. However,  
> let's assume that there's some heavy synchronous computation taking  
> place that causes several battery events to be queued. When the queue is  
> finally ready to be processed, a listener will suddenly receive a rapid  
> burst of battery events.

You can avoid queuing if an event will already be dispatched. You could  
also define a specific task source for battery events and empty that when  
you queue an event. I do think you should make sure that updating  
attributes happens at the same time as the event is dispatched and not  
before. Otherwise you get code that checks such an attribute at one point  
and later without an event being dispatched it suddenly has a different  
value. So far we have kept such surprises to a minimum.

>> You also need to actually define the various on* attributes as being  
>> event handlers and update their IDL to match the latest crazy IDL  
>> syntax (which might be simplified, so maybe you want to wait for that).
> Are the on* attributes needed? I never really liked on* attributes,  
> given that they are so much limited compared to real event listeners  
> added through the addEventListener method. Personally I'd remove them,  
> and instead better define the events.

It's typical to have event handlers for convenience. Cannot really think  
of an API that does not use them.

Anne van Kesteren

Received on Wednesday, 30 November 2011 12:40:23 UTC