element.on.{EventType} doesn't scale much with custom events where prefixes
are in place, i.e. "jquery:transform" or whatever other string used to
create unobtrusive custom events or ... will it? Same is for
element.on({EventType:cb|handler})My best version of on follows same addEventListener signature except it returns the element itself and accepts an array of types as overload element.on( type:string|string[], handler:Function|Object (with handleEvent), capture:Boolean (false by default) ):element the counter part is semantically easy to remember ... element.off( ... same as above ... ):element the ability to reuse a single callback or object with handleEvent together with the ability to use arrays of event types makes state machine like event driven interaction a piece of cake, IMHO. My 2 cents On Mon, Jan 7, 2013 at 8:42 AM, François REMY <[email protected] > wrote: > Hi Anne, > > Thanks for bringing the case of event registration, this has been a pain > in DOM/JavaScript for some time already and it's quite clear we can do > better in this area. > > However, I've a few issues with your latest proposal: > > - how do you register more than one handlers for an event? > - how do you unregister an handler with this proposal? > - how do you specify properties for your handlers (like shouldCapture)? > and > - isn't creating an object bag a too high cost for an event > registration? > - how do you deal with private names and inherited properties? > > What about resurrecting .{} instead? > > element.on.{ > click.{ > remove(oldCallback1) > add(newCallback1) > } > resize.add(newCallback2) > } > > Even if .{} isn't resurrected, I think an 'on' proxy still leaves you with > a fairly good syntax: > > element.on.DOMContentLoaded.**remove(...).add(...).add(...); > > If we define "element.on" as a proxy, we can event make it support unknown > event names by returning an "event handler object" for the event whose name > as been specified as property name. > > That would leave us with two new WebIDL interfaces, and an updated one: > > interface EventTarget { > readonly EventRegistrationHub on; > } > > interface EventRegistrationHub { > readonly EventTarget target; > /* proxy, returns an event handler for unknown properties whose > target is 'target' and whose 'name' is the required property name */ > } > > interface EventHandler { > readonly DOMString name; // the name of the event > readonly EventTarget target; // the target of the event > add(callback, options...) // ... > remove(callback...) // ... > } > > Another benefit is that you could pass an event to a function (now, you > have to pass the target and the name, and use > target.addEventListener/**removeEventListenee(name, > ...)). > > Another benefit could be that now you can check for the existence of an > event by doing if("EventName" in target.on), if we configure the proxy > correctly (ie return true only if the event is builtin). New events always > come with an uppercase first-letter name so that we can be sure there will > be no conflict with future Object.prototype.* builtin properties (if > there's not one already with the current names, which I believe is not the > case). > > Last but not least, you can get intellisense (autocompletion) once you > typed "element.on." in any sufficiently good IDE/dev tool. > > Best regards, > François > > > > > -----Message d'origine----- From: Anne van Kesteren > Sent: Monday, January 07, 2013 2:25 PM > To: es-discuss > Subject: Object iteration order > > In "DOM-land" we're designing new APIs that take objects as arguments. > Unless objects meet the criteria in > https://mail.mozilla.org/**pipermail/es-discuss/2010-** > December/012469.html<https://mail.mozilla.org/pipermail/es-discuss/2010-December/012469.html> > invocation of the API method might result in implementation-specific > behavior. See also > https://www.w3.org/Bugs/**Public/show_bug.cgi?id=20158<https://www.w3.org/Bugs/Public/show_bug.cgi?id=20158> > > Given the convenience of being able to do something like > > element.on({click: callback1, resize: callback2}) > > we're probably going to run with it, but I thought I'd give a heads > up. Maybe someone here has a better idea or maybe iteration order will > finally be settled on? :-) > > > -- > http://annevankesteren.nl/ > ______________________________**_________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> > ______________________________**_________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
