Re: Feedback about Battery Status Events

On Mon, Oct 24, 2011 at 12:20 AM, Anssi Kostiainen
<anssi.kostiainen@nokia.com> wrote:
> 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).

Sounds great!

/ Jonas

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