- From: <bugzilla@jessica.w3.org>
- Date: Tue, 23 Jul 2013 04:38:41 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22757 --- Comment #6 from Cameron McCormack <cam@mcc.id.au> --- (Mid-aired by Boris, but can't be bothered editing my reply to remove duplicate information...) (In reply to comment #4) > Your assumption that specs don't say anything about a particular scenario is > not very nice, since most often they do. That's what I meant, I don't need a > dictionary definition. > > As for invoking the callback, it's done in > http://dom.spec.whatwg.org/#concept-event-listener-invoke (4.7 at the > moment). I kinda thought IDL would handle the Function/handleEvent > distinction. I guess not. > > heycam, suggestions? Web IDL does handle the Function vs { handleEvent: ... } differences, so you shouldn't need to handle the two cases differently. If you want, you can define the callback this value regardless of whether a Function object was used -- the callback this value will only be used when it is a Function object, anyway. Might be good in that case to have a note to point out that if a { handleEvent: ... } object is passed then that object is the this value. Boris is right that it needs to specifically talk about calling handleEvent on the object, since callback interfaces are things which in general can have any number of operations on them. (Even if a Function object were used, its [{Call]] behaviour is considered as the implementation of the handleEvent operation, so it still makes sense, wrt Web IDL, to talk about handleEvent there.) Such is the difference between callback interfaces and callback function types. If it's helpful, I can add a term you can link to for calling an operation on a object that implements a callback interface. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Tuesday, 23 July 2013 04:38:42 UTC