The following avoids browser sniffing for IE's submit.
It simply creates a div inside a form, then dispatches a submit event
and sees if it bubbles.
I'll see if something similar works for change in Safari and IE.
jQuery(function(){
var sendEvent = function(type, element){
var event;
if (element.ownerDocument.createEvent) {
event = element.ownerDocument.createEvent("Events");
event.initEvent(type, true, true);
}
else {
event = element.ownerDocument.createEventObject();
event.type = type;
}
if(element.dispatchEvent){
return element.dispatchEvent(event)
}else{
try {window.event = event;}catch(e) {}
return element.fireEvent('on'+type, event);
}
}
var div = document.createElement("div");
div.style.display = 'none'
div.innerHTML = "<form action='run'><input type='submit'/></form>"
var form = div.firstChild;
document.body.appendChild( div );
jQuery.support.submitBubbles =false
$(div).submit(function(ev){ jQuery.support.submitBubbles =
true;ev.stopPropagation()})
$(form).submit(function(ev){ ev.preventDefault();})
sendEvent("submit",form)
document.body.removeChild( div );
div = null;
form = null;
alert(jQuery.support.submitBubbles)
});
On Sep 14, 12:16 am, Justin Meyer <[email protected]> wrote:
> WARNING: Skip to the end to avoid an in depth discussion of the
> problems, and the only questions I need guidance.
> ------------------------------------------------------------------------
> I'm going to replace JMVC's delegation
> lib:http://code.google.com/p/javascriptmvc/source/browse/branches/2_0/jmv...
> with live.
>
> I've mentioned this once before, but I'm energized after hearing
> almost everything I wanted previously is a priority.
>
> I was under the impression that the current (trunk?) code supported
> submit, but after testing, it seems like it doesn't work in IE. The
> code seems to speak to that too. Am I looking in the right place?
>
> A few thoughts on live and using delegation. Performance of closest
> is critical if you want to support events like mouseover choosing
> between > 10 different selectors. In almost all cases, getting the
> parentNode list is the most expensive part. This is from a lot of
> experience with JMVC, and it only has to calculate this list once. To
> support rapid event delegation, I suggest adding a 2nd parameter to
> closest which would be a cached array of the parent list.
>
> I've been sorta shot down by Brandon, but I don't like having to run a
> query when I attach live functions. If I have 10s of thousands of
> '.todo' elements on my page (which is the reason I am using live in
> the first place), I don't want to have to do a $('.todo'). Using
> 'live' is familiar to those who used liveQuery, but delegate would be
> a better name.
> $().delegate('.todo','click',function(){ ... })
> But, I realize that this is almost certainly never going to happen.
> Maybe there can be a $.live where I can provide the context?
>
> The next suggestion would be adding a stopPropagation to event.
> LiveHandler would check if it has been called and will simply stop
> delegated events on the element without returning false from
> liveHandler. There are many cases where this is needed in our code.
>
> But getting to the most important question - how to get submit and
> change working?
>
> For submit and change, you have to listen to multiple events (and
> later be able to stop listening). It doesn't seem there is a good way
> to do this in event.add. What would be the best way of doing this?
>
> JMVC uses before and after filters for certain event / browser pairs
> to make sure things are ok. For example, in IE you listen for clicks
> + keypress instead of submit. The beforeFilter makes sure the target
> is an submit input.
>
> For change in IE on a select, I listen for clicks, make sure the
> selector matches the element, then the after filter checks if there is
> a value (in $.data("_change_data")). If not, there hasn't been a
> change, so it saves the current value. If there is a value, and it is
> different, the filter 'approves' the change.
>
> There are a few issues with this. The most important is that I am
> browser sniffing like crazy. I'm not sure if this can be done w/o
> browser sniffing. The only thing I think could even work is creating
> a form, dispatching a synthetic 'submit' event via fireEvent/
> dispatchEvent. Obviously, that would suck and I am not sure it will
> even work. I'm open to suggestions before I try.
>
> The second issue is that I am putting data in _change_data. Is there
> a better place for this?
>
> Another thing, you need to have capture option passed to event.add so
> focus and blur will work.
> event.add = function(elem, types, handler, data, capture){ ...}
> Would this be ok?
> ---------------------------------------------------------------------------
> ------
> So, I can happily build all of this if I can get guidance on the 2
> most important problems:
> Best way to listen and remove multiple events for a single delegated
> event? (EX: delegate on submit, listen for keypress and click)
> How to avoid browser sniffing. (EX: know that submit doesn't bubble in
> IE).
>
> Thanks!
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---
