- From: Anne van Kesteren <annevk@opera.com>
- Date: Wed, 31 Aug 2011 13:31:25 +0200
- To: "Anssi Kostiainen" <anssi.kostiainen@nokia.com>, "Robin Berjon" <robin.berjon@gmail.com>
- Cc: "public-device-apis@w3.org WG" <public-device-apis@w3.org>
On Wed, 31 Aug 2011 13:21:55 +0200, Robin Berjon <robin.berjon@gmail.com> wrote: > 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. Modifying how addEventListener() works violates DOM Core. Not really acceptable. > 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. They are orthogonal. Event handlers are a convenient way to listen for an event whereas new Event() is a convenient way to create an event. > 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. I think initBatteryStatusEvent() should be dropped. New specifications should use the DOM Core event constructor mechanism and not further proliferate init*Event() methods. -- Anne van Kesteren http://annevankesteren.nl/
Received on Wednesday, 31 August 2011 11:32:00 UTC