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

Hi Joćo,

On 6.9.2011, at 2.44, ext Joćo Eiras wrote:

[...]

> If stop() exists solely to tell the user agent that no more events need to be dispatched, then doing removeEventListener can be handled the same way (and should be), just like suggested for addEventListener. addEventListener and removeEventListener aren't magic or too transparent like a GC. The user agent can tell if there is a listener or not and setup the proper system hooks, if need be. You can add a non normative hint for implementors.

That is a good point. I'll drop stop() and add a non-normative note for implementors. Would something like the following sound right: "when the [battery] object has no registered event listeners, its task source can be disabled as an implementation optimization technique."

Feel free to suggest a better wording.

[...]

> And a small nit pick
> - http://www.w3.org/TR/battery-status/#widl-BatteryStatusEvent-isPlugged
> Perhaps isPlugged would be better named as isCharging. Or it should be isPluggedIn :)

isCharging would not be semantically correct, because if the battery is full it is not necessarily charging. I think isPlugged (and not isPluggedIn) was chosen for brevity. I guess naming is not the biggest issue with the spec at the moment so I'd suggest we leave the name as is for the time being :)

Thanks for your helpful comments.

-Anssi

Received on Wednesday, 7 September 2011 11:05:33 UTC