jQuery Forum

Just wanted to announce the new versions of the drag and drop special event plugins. A completely event based API to create complex drag and drop interactions. There are lots of new features, new documentation, and 40 different demos to illustrate how the events can be used to achieve many standard interaction patterns.

http://threedubmedia.com/code/event/drag/

Version 2.0 Features:

- Simultaneous Multiple Drag
- Live Drag Delegation
- Shared Callback Object
- New Drag Properties

http://threedubmedia.com/code/event/drop/

Version 2.0 Features:

- Simultaneous Multiple Drop
- Live Drop Delegation
- Shared Callback Object
- Improved Drop Target Management

In case anyone is interested, I just stumbled on this product from
google...
http://code.google.com/closure/
With a web interface and REST API
http://closure-compiler.appspot.com/home
And a Firebug extension...
http://code.google.com/closure/compiler/docs/inspector.html
--

Trigger succeeds (1.3.2): http://jsbin.com/ixege
Trigger fails (nightly): http://jsbin.com/owisi
(Firefox 3.5.2/Vista)
http://dev.jquery.com/ticket/5124

I have a small demo system, where you can edit and execute source code
directly in the same page, and load and execute new demo pages using
ajax. When attempting to upgrade to the 1.3.3 nightly (2009-07-25,
rev. 6507). I noticed some problems with the script execution. I have
put together two paired down sample pages.
The first includes 1.3.2 and behaves correctly:
http://jsbin.com/utita
The second includes 1.3.3 (nightly) and fails for me on the 3rd
execution:
http://jsbin.com/ijuze
Otherwise, the pages are identical.
http://dev.jquery.com/ticket/4981

I have not been able to open the latest jquuery nightly build
(1.3.3pre) in Dreamweaver CS4 (64bit Vista).
The program crashes every time I open the file, or another page that
includes the file. I have no problems with the same files on CS2
(XP).
Has this happened to anyone else? Does anyone else with CS4 want to
double check?
Thanks in advance,
mike

I propose adding a second argument to the "closest" method that will
act as the end point for searching up the document tree. It can behave
just like the "context" argument in the jQuery mother function. It
will optimize the performance of a common pattern I have seen in my
own code since the addition o this method.
$("table").bind("click",function( event ){
var $td = $( event.target ).closest("td", this );
});
Because I bound the handler to "table" I do not want to search an
higher than that element for selector matches. Furthermore, if there
was a selector match outside of the containing element, it could
potentially and accidentally be matched.
http://dev.jquery.com/ticket/4945
Any thoughts?

- The selector must be run, before the event handler is bound... this
seems less than ideal, if a large number of DOM elements already exist
- Always binds/listens to the document. My biggest hesitation with
using live for delegation, is that there is no way to control the
listener, it is always the document. It should at least use the jquery
collection's context.
- Functionality is private... would like to expose the internal
functions "liveConvert" and "liveHandler" to enable a plugin to
leverage some of the features.
- Can't attach data to handlers the way you could using "bind"
- Events don't bubble correctly. Using the "closest" method seems like
the wrong solution here... I love the method, it is quite useful, but
in this case it causes elements to need to be sorted, and stops the
event from bubbling the way events should
- Events and handlers are not cancelable... because of the way the
liveHandler works.
For the benefit of those who have not looked at the code...
"liveHandler" goes through all of the stored "live" handlers/
selectors, checks each handler for a matching event.type, then takes
the event.target and searches for the closest selector match. (This
means starting with the given element and walking up the parent tree
and testing the selector against every element until a match is found,
and storing the number of "parents" away the match is made) Then
matched elements and the current handler are stored in a temp array.
Afterwards, "liveHandler" sorts by "closest" then iterates the temp
array to finally call each handler. This all makes terrific sense, but
the biggest drawback for me, is that each handler is only called on
the first matched element.
If I have nested divs, I would expect the "live" handler for "click"
on selector "div" to get called twice. This is (currently) not the
case. To try to work out some of these issues, I have created a plugin
to try to fix most of these issues. Here is what I tried to
accomplish:
1) Exposes some of the private methods so that future plugins can
modify things a little more easily.
2) Bind the event listener to the jQuery context instead of the
document. (I think there must be a larger issue at play here) This
also only seems to work, by setting the context with a raw DOM element
like: $( context ).find( selector ) or $('selector',context).
3) "Better" bubbling/canceling... if a handler returns false, that
handler/selector stops. if event.stopImmediatePropagation() is called,
all handlers and selectors are stopped.
4) Creating a new method for setting up delegation without calling the
selector... using "liveConvert"
$( context ).delegate( type, selectot, handler );
Not sure yet about data... anyway, here is some code I have been
working on and some very basic tests...
http://dev.helgeson.info/live/
http://dev.helgeson.info/live/$.live.js
I know that there is probably some issue with "position" selectors,
but I just want to try to improve this powerful feature...

I provided a patch about 8 months ago to improve the performance of
the core height and width and dimensions inner/outer[height/width]
methods.
http://groups.google.com/group/jquery-dev/browse_thread/thread/a4becc9a5cc34fea/
I put together a test page to help make my point...
http://dev.helgeson.info/dimension/
I average the following results using FF3/XP...
(percentages of the unpatched method time)
height & width ~ 73%
innerHeight & innerWidth ~ 44%
outerHeight & outerWidth ~ 19%
outerHeight( true ) & outerWidth( true ) ~ 32%
I updated the patch to be compatable with 1.3.x
http://dev.jquery.com/ticket/3082
In addition to being more efficient, the methods also simplify the API
by overloading the height/width methods. By passing in a string
("padding" or "border" or "margin") you get in return, the dimension
through that property.

Not sure if this is considered a bug, but it breaks some of my code...
Passing any non-element into the offset method throws an error... I
think it should instead return zero values...
$( document ).offset(); // ERROR
$( window ).offset(); // ERROR
Here is a very simple proposed patch...
http://dev.jquery.com/ticket/4136

Take a minute to check out this plugin. Have you ever needed to
capture dragging in a plugin or application, but didn't want to
introduce big dependency files? This plugin creates custom events,
that work exactly right, for less than 2k when packed. New release
came out today and I recommend it for anyone!
http://plugins.jquery.com/project/drag
Check out these demos
http://threedubmedia.com/demo/drag/
I encourage everyone to give the special events API some love.

Event delegation is on the roadmap for 1.3
http://docs.jquery.com/JQuery_1.3_Roadmap
My question is: Who is taking the lead on this particular task?
I have some thoughts and solutions for event delegation that are a
little more robust than Joern's delegate plugin. For the solution that
makes it into the core, I would expect to see the following features
and functionality for event delegation:
- Data, event data as is currently supported in the event system
- Bubbling, starting with event.target, and traversing up the parent
tree to match the delegate selector
- Canceling default event behavior, parent tree-walking, other
delegate handlers on the same element
- Intelligent Removal, being able to remove all delegates, remove
delegates by event type (or namespace), event type and selector (and
sometimes handler)
I have some code I can share with anyone who is interested, it is a
first pass at all of these features. I would also like to know the
thoughts and expectations of other developers who have ever used event
delegation, especially around cancellation.
-mike

I am wondering: what is the general philosophy for the jquery core
regarding coding "macros" which take a little time to execute but
reduce the file size of the library or a plugin. I have noticed macros
used, for example, on the core height/width functions and the event
bind/trigger shortcut functions (the usage there is a clear no-brainer
as 20 functions are created in about 7 lines). But what is the cost/
benefit threshold of this practice (what should I do if I notice
additional potential size reducing macros). Based on what little I
understand about gzipping, the shorter code will not always compress
to the smallest, so what practices should be observed to optimize
compression?
-mike

I would like to request that the special event setup function calls
get passed the data parameter as a means to configuring the special
event. The change would be made on line 1883 of 1.2.6:
... jQuery.event.special[type].setup.call(elem) ...
would become
... jQuery.event.special[type].setup.call(elem,data) ...
http://dev.jquery.com/ticket/3112

I don't know if anyone has experienced a performance issue with global
event triggering, but in my opinion the jquery core should not ever
call jQuery("*") internally.
After investigating this unloading issue:
http://dev.jquery.com/ticket/2698
http://groups.google.com/group/jquery-dev/browse_thread/thread/bdb96e4c77c6cf79#
...I noticed another potential bottleneck with the global event
triggering on line 1985 in 1.2.6 (uncompressed)
jQuery("*").add([window, document]).trigger(type, data);
I think this should be replaced by:
jQuery.each( jQuery.cache, function(){
if ( this.events && this.events[type] )
jQuery.trigger( type, data, this.handle.elem, true );
});
Opinions?

I am trying to bind multiple custom name-spaced events with one
handler and it seems that only the final event gets added... This
feels like a bug to me, but maybe there is some logical reason for it?
$(window)
.bind( "test.one test.two", function(ev){
console.log(ev.type+'.'+ev.handler.type);
})
.trigger("test.one").trigger('test.two');
The same result happens if I try it this way...
var fn = function(ev){ console.log(ev.type+'.'+ev.handler.type); }
$(window)
.bind( "test.one",fn).bind("test.two",fn)
.trigger("test.one").trigger('test.two');
I only get the expected result when using unique handlers...
$(window)
.bind("test.one",function(ev){
console.log(ev.type+'.'+ev.handler.type);
})
.bind("test.two",function(ev){
console.log(ev.type+'.'+ev.handler.type);
})
.trigger("test.one").trigger('test.two');
Shouldn't I be able to bind multiple events with one handler?
Is the problem I am having because of the name-spacing?
Using different types of events and one handler works as I expect...
$(window)
.bind( "test1 test2", function(ev){ console.log(ev.type); })
.trigger("test1").trigger('test2');
Do I have the name-spacing backwards? If I am trying to publish/
subscribe custom events in a plugin, should the event be called
"plugin.disable" or "disable.plugin"? I thought the former... now I am
not so sure.

The new "special" events api seems very solid, but is there a plan for
documenting it's use?
It seems straight forward enough that "$.event.add" looks for
"$.event.special[event].setup" and "$.event.remove" looks for
"$.event.special[event].teardown" but to use
"$.event.special[event].handler" the special event author must call it
specifically from within "setup/teardown"? Is it acceptable to use a
scoped function instead of the long name-spaced "handler" (like is
done for "$.event.special.ready")?
Has anything else event-wise changed (other than "hover",
"mouseenter", "mouseleave")?
I am in the process of deciding whether or not to upgrade to this new
version and am experiencing problems with many of my plugins, mostly
with events. In some "keypress" events, event.which is coming up as
"0" quite often, and it seems that some other events (vanilla ones
like "click" and "mouseover") are getting bound but not firing. I
can't figure out why. Anyone else experience any problems?