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

Hi Anssi,

thanks a lot for working on this, very good job!

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.

> * ISSUE-114: Battery spec should note relative ordering of battery low versus battery critical in terms of criticality
> 
> I've added prose to make this clearer.

+1

> * ISSUE-115: Do you get the batterylow event when you're charging and cross that boundary?
> 
> As discussed, firing less events is better for (battery) performance, thus I propose the batterylow and batterycritical events are only fired if the battery is depleting while crossing the boundaries.
> 
> I've added prose for that.
> 
> (In some implementations even if the device is plugged in the battery could deplete under heavy load. The proposed design leaves it to the implementation to figure out if the events should be fired while charging.)

This resolution makes sense to me.

> One more thing (should not block CfC for LC though):
> 
> * There was discussion on Geolocation WG ML about Device Orientation and bringing back window.on* handlers, Doug also recently implemented those to Firefox:
> 
> http://lists.w3.org/Archives/Public/public-geolocation/2011Jul/0017.html
> 
> Those handlers were removed from Battery Status Events spec couple of revisions back as per Doug's request:
> 
> http://lists.w3.org/Archives/Public/public-device-apis/2011Jun/0058.html
> 
> Should we pave the newly established cowpath and revert that change? 

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.

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.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

-- 
Robin Berjon
  Robineko (http://robineko.com/)
  Twitter: @robinberjon

Received on Wednesday, 31 August 2011 11:22:35 UTC