It seems like a bug, as 1.3.1 is behaving differently from 1.2.6.
I posted errant's example to jquery-dev, let's see what they have to
say.
http://groups.google.com/group/jquery-dev/t/f18e4a06e11fdb87
On Jan 27, 4:01 pm, Eric Garside wrote:
> I don't think it's a bug. I think it's just another
Some may see the fact that future handlers are automatically assigned
based on a given selector as a side-effect if it were incorporated
this way on a set of DOM elements (though using live()/die() makes
more sense). All I'm saying is that if append is going to
automatically clone a DOM element i
I don't think it's a bug. I think it's just another example of IE's
lack of standard compliance.
On Jan 27, 12:53 pm, errant wrote:
> jQuery provides many ways to achieve similar results, sometimes
> decision which way to use is up to developer. Personally, in first
> example i like to have refe
jQuery provides many ways to achieve similar results, sometimes
decision which way to use is up to developer. Personally, in first
example i like to have reference to span element with attached event
handlers without extra code. Maybe i'll use it in some other way later
in code. Anyway, append() g
Honestly, I'm at a loss why I'd want that kind of temporary cloned
functionality when you could just use live to achieve the same
functionality with nowhere near the limitations of the implementation
you've described here. It's also nice to be able to excise my event
declarations from my dom manip
of course if there are other things that may need to be customized
about the event(s) in question it might make more sense to pass in an
options object.
On Jan 27, 11:30 am, jay wrote:
> I thought the point was to avoid the each()? What's wrong with:
>
> $('ul li').append($('Click me!').click(f
I thought the point was to avoid the each()? What's wrong with:
$('ul li').append($('Click me!').click(function(){},
true);
and doing $('ul li').append($('Click me!').click(function
(){});
defaults the second argument to false.
Or you could default it to true and it may stay more backwards-
c
You can already do that using clone. I can't see a need to rewrite in
new code when the ability already exists in the current code. If you
want to clone around your elements around and not apply new styles,
just:
$('ul li').each(function(){
$(this).append($('Click me!').click(function(){}))
})
It's not that I prefer it. I think live()/die() makes sense because
the event "lives on" for all matching selectors. What the true
arguement would do it give a way to clone the element and it's handler
just that one time.
On Jan 27, 10:50 am, Eric Garside wrote:
> Give them a different selecto
Give them a different selector?
$('.click1').live('click', function(){});
$('.click2').live('click', function(){});
Would handle the problem easily. Remember, you can always add extra,
non-style based classes which you can use as selectors for events or
effects.
Also, I'm not sure I understand
live() works, but it involves extra steps. For example something like
el.click(fn,true) maybe be easier to remember for some. Also live
differs from what I was thinking in that it continues to bind events
to the handler based on the selector. I was thinking it should only
be cloned that one tim
> Perhaps there should be an optional boolean passed to the event
> handlers to specify carrying over event handlers like there is with
> the clone() method?
There is. That's exactly what live() does. You just define it before
runtime.
On Jan 27, 10:06 am, jay wrote:
> It actually makes sense,
It actually makes sense, because you've only created one element here:
var handle = $('Click me');
By doing append() on a set of elements using this one element, it may
be implying you would like to clone this element for the elements
after the first one, but it's not completely obvious. Someth
Actually, quite the opposite. The living events provide a unique way
for handling callbacks. It'll actually trim down the amount of code
you use substantially. For 90% of the situations I can imagine, using
the generic live() binding cleans up the code, and makes it easier to
read/handle on my par
Hi Eric, thanks for response.
Yes, it works that way, but it's kind of unflexible and may be
impossible to implement when dealing with more complex code, don't you
think?
On 27 янв, 17:29, Eric Garside wrote:
> I believe it has to do with the new event propogation model
> implemented with 1.3
>
I believe it has to do with the new event propogation model
implemented with 1.3
Instead, try using a living event:
$('ul li span').live('click', function(){
// ...
});
$('ul li').append('Click me');
That should work.
On Jan 27, 8:15 am, errant wrote:
> Here is the
16 matches
Mail list logo
