Re: Battery Status API changes since the last publication

On Monday, 16 April 2012 at 13:23, Anssi Kostiainen wrote:

> Hi Marcos,
>  
> Thanks for your comments. And welcome to the group :)
>  
> [I should have probably mentioned that the mail summarizing the changes was an informative one and all the changes listed have already been discussed on the mailing list and agreed by the working group. There are also multiple independent implementations.]
Ok. Thanks for letting me know :)    
>  
> On 16.4.2012, at 12.39, ext Marcos Caceres wrote:
>  
> > On Monday, 16 April 2012 at 09:03, Anssi Kostiainen wrote:
> >  
> > > - Added [TreatNonCallableAsNull] keywords to on* handlers.
> >  
> > Note that [TreatNonCallableAsNull] is still in flux in WebIDL. I strongly recommend emailing the WebIDL list about this for guidance before proceeding (might save a bit of a headache later). Event handlers may end up being defined in DOM4.
>  
> We want to avoid blocking on that, if at all possible. [TreatNonCallableAsNull] (or an equivalent) is required by various handlers in the HTML5 spec and others by both legacy and "new" APIs. My suggestion is we follow the lead and adapt when the dust settles, if needed, but go forward with what we have now.
>  
> My understanding is that in this case we can adjust the spec after entering the CR without the need to jump through too many hoops. Let's not get the process get on our way.
>  
> (I think the general question here is how to deal with an unstable Web IDL as a normative reference.)

Ok, but you should still email them regardless. WebIDL strongly encourages the WG to do so - if only as a (non-blocking) formality. It's important to inform the WebIDL people that people are using [TreatNonCallableAsNull]:  

"Specifications should not use [TreatNonCallableAsNull] unless required to specify the behavior of legacy APIs or for consistency with these APIs. Specification authors who wish to use this feature are strongly advised to discuss this on the public-script-coord@w3.org mailing list before proceeding. At the time of writing, the only known valid use of [TreatNonCallableAsNull] is for the callback functions used as the type of event handler IDL attributes ([HTML5], section 6.1.6.1) such as onclick and on error."

   
> > > - Dropped 'full' from the true condition for the charging attribute.
> > > - Fixed two substantial typos (s/dischargingchange/dischargingtimechange/g) in the Event handlers section.
> >  
>  
>  
>  
> [...]
>  
> > I'll note that it seems pretty extreme to have four different event registers that basically do the same thing: detecting a change in charge. Why don't you merge them into a "onchange" attribute?
>  
> Basically the gist of the design is we don't want to fire unneeded events. Especially on an API that is there to help save same battery.
This seems like an unnecessary optimisation in a soup of un-optimized stuff (has anyone done the Math here to prove that there would be any battery savings?… also, how often events are fired would be controlled by the platform… and you still need to do the lookup synchronously when you query the properties on the BatteryManager… so I don't see much win here… it's getters all the way down.). Developer's ability to use the API easily should always win over such things.   
> > Also, the spec says that BatteryManager is an EventHandler, yet no events are fired at it (that seems wrong - event handlers need to have events fired at them)?  
>  
>  
>  
> Actually, all the events are fired at the BatteryManager object.
Ok, I see now. You are firing a simple event named e as per HTML5. I was expecting a BatteryChangeEvent.  I guess this can be extended in the future if need be. I'll note that events with no details are not great.

Received on Monday, 16 April 2012 13:14:11 UTC