Re: Feedback about Battery Status Events

On 22.10.2011, at 5.12, ext Jonas Sicking wrote:

> On Tue, Oct 18, 2011 at 7:06 AM, Anssi Kostiainen
> <anssi.kostiainen@nokia.com> wrote:
>>>> I like your proposal's clearly named *change events (should they be prefixed with battery, e.g. statuschange is a rather generic name for an event?).
>>> 
>>> The events are fired on the BatteryManager object. It doesn't seem useful to prefix those events with "battery" then.
>> 
>> If the *change events do not bubble then more terse names are better. But if we want to have them bubble then wouldn't this be valid, but a bit ambiguous:
>> 
>> window.addEventListener('levelchange', function () {}, false);
>> 
>> Are there any use cases for bubbling? If bubbling is not needed then your proposal sounds good to me.
> 
> So note that we shouldn't really talk about bubbling vs. not bubbling.
> Instead we should talk about propagation path. The reason is that
> *all* events have a capture phase, which follows the propagation path.
> The bubbling events just follow that propagation path the other
> direction. So the question is if the window object should be in the
> propagation path for events fired at the battery event.
> 
> The main reason for having propagation paths through an object is to
> allow event listeners on that object to observe events fired at
> multiple objects. So for example you can listen to "click" events on
> the Document to observe "click" events fired at any Node in that
> document.
> 
> However here there's only one battery object, so I can't think of any
> reason to listen on the window object rather than directly on the
> battery object.
> 
> So I would say that there's no reason to let the events propagate
> anywhere other than just the battery object. This is similar to for
> example XHR, EventSource, WebSocket and FileReader.

Thanks for the clarification. Given that the events are only fired at the BatteryManager, simple events are what we need. This is what's in the latest draft:

[[

When the value of chargingState, level or remaining attribute changes, the user agent must fire a simple event [HTML5], which does not bubble and is not cancelable, named chargingstatechange, levelchange or remainingchange respectively at theBatteryManager object.

]]

Let me know if there are any concerns (charging vs. chargingState naming and semantics aside).

-Anssi

Received on Monday, 24 October 2011 07:21:23 UTC