Ariel, jQuery is already doing very well in many fields, the suggestions were to cover expressed needs not to leave out working code.
I will follow on your answers... On 29 Nov, 16:22, "Ariel Flesler" <[EMAIL PROTECTED]> wrote: > @Scott > > Ok, that's an easy change (leave it or remove it). The question is, > what's the formal application of this extra function ? > > @Diego > > We don't have the needed hacks to implement event capturing in IE (I > know your NWEvents does). We don't plan to add that I think, that > requires a lot of hacking and not many would benefit from it. > So why add that parameter to our method ? > Hey, I didn't invent that capture flag, nor the need for it...the fact is well documented in W3C specifications, it has been there for long, ignored by jQuery though. There are several techniques and methods that were not available in IE and were fixed or emulated by jQuery, or a workaround was found for it. The question should be turned to: why did jQuery ditched that standard and very useful parameter ? Or, why should users load a framework to learn a different and mangled way of setting up javascript events ? We probably disagree about what W3C specifications are for, I for myself believe they did it for the benefit of many. There are many useful things that can be done with the capture flag, you have code parts both in core and in various plugins that would benefit from this. After loading a 50Kb framework I wouldn't expect being forced to write standard javascript to achieve events working as described by 4 vendors over 5, this makes code size bigger and duplicated in each plugin needing this extra event functionality. We are still not talking about delegation...and benefits there. > I've been thinking about trying native event triggering instead of > what we have now. I showed that old experiment where I achieved native > event bubbling on all browsers, even for custom events. But that > required quite a large amount of code, maybe we can leave that as a > plugin. > Programmatically dispatching events using native methods seems to me much shorter (and faster) than constructing an emulated event object and looping through the handlers. All browsers can handle that natively. In reality both methods of dispatching/triggering events should be available, this is also the standard W3C way of doing it (for DOM elements only, not for custom or object events). > About the event properties from the originalEvent... jQuery "claims" > it normalizes event objects in a cross browser way (some properties). > Telling the user "look for them on the original object" doesn't seem > too nice for me. > The needed properties should already be there as needed, my suggestion was about maintaining the information and passing it down the chain, making it possible to reference the original event and properties should they be needed. For example, if I am not wrong the iPhone keep information about several events in the main event object to handle touch events and be multi-touch aware. This is similar to what I propose. > Thanks both for replying. Thanks you for the hard work, -- Diego > > Cheers > > On Sat, Nov 29, 2008 at 1:08 PM, Scott González > > > > <[EMAIL PROTECTED]> wrote: > > > jQuery UI uses the return value of triggerHandler, but we only care > > about false, so this change shouldn't affect us. > > > What's the logic behind removing the event from the extra function? > > If I remember correctly, I talked to John about this a while ago and > > he couldn't think of any reason why that was done. I created a ticket > > to remove this behavior and it has just been sitting in Trac for 5 > > months (http://dev.jquery.com/ticket/3096). > > > On Nov 28, 7:14 pm, Ariel Flesler <[EMAIL PROTECTED]> wrote: > >> Feedback please! :) > > >> I really like (and support) this feature. > > >>http://dev.jquery.com/ticket/3662 > > >> Also... I know that the returned value from jQuery.fn.trigger is used > >> here and there (jQuery UI?). But that behavior is really odd and > >> fragile in my opinion (false overrides any previous value). > > >> I think it'd be nice to return true/false depending on whether > >> e.preventDefault() was called. This would be very useful for custom > >> events, to allow event handlers to stop a scheduled (custom) behavior. > > >> As an alternative, we could add e.isDefaultPrevented() that retrieves > >> this value from the event object. > > >> Note that none of this last 2 behaviors (or the one in the ticket) is > >> my invention. > >> I'm just imitating AS3's event system. I suppose that belongs to some > >> EcmaScript specification as well. > > >>http://docs.brajeshwar.com/as3/flash/events/Event.html > > >> Thanks > > >> -- > >> Ariel Fleslerhttp://flesler.blogspot.com > > -- > Ariel Fleslerhttp://flesler.blogspot.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~----------~----~----~----~------~----~------~--~---
