On Apr 9, 2:20 pm, buda wrote:
> And how about this behaviour as an option parameter in Remove method?
> I dont stand on it but to realise every time helper method - is not
> write way!
We don't remove event handlers because `remove` is not a final
operation. `remove` removes an element from the
sorry - there is a misprint "write" - right
On 9 апр, 21:20, buda wrote:
> And how about this behaviour as an option parameter in Remove method?
> I dont stand on it but to realise every time helper method - is not
> write way!
>
> On 9 апр, 19:08, "T.J. Crowder" wrote:
>
>
>
> > > But for
And how about this behaviour as an option parameter in Remove method?
I dont stand on it but to realise every time helper method - is not
write way!
On 9 апр, 19:08, "T.J. Crowder" wrote:
> > But for novices it would be surprise -
>
> I'm trying really, really hard not to say "Lots of things are
> But for novices it would be surprise -
I'm trying really, really hard not to say "Lots of things are
surprises to novices." ;-) (And I just failed, of course.)
Speaking seriously, though, I for one wouldn't have any objection to
mentioning the need to remove handlers in the Element#remove doc
But for novices it would be surprise - they extend elements, add to
them event-listeners, add some extra-properties to storage and after
removing elements they would expect, as it was with extending,
auto-"cleaning" memory - but it wold not success
On 9 апр, 18:23, Robert Kieffer wrote:
> On Apr
@Trevan:
> I don't think it should be default as it is very slow.
*Exactly*
@buda:
> It seems to me that this behavior should be by default...
The consensus in the previous thread was: No it shouldn't, not in the
general case, and of course the general case is what Element#remove is
for.
I
On Apr 9, 6:42 am, buda wrote:
> It seems to me that this behavior should be by default and if I not
I disagree. This would raise serious performance issues. I side with
T.J. on this one.
--~--~-~--~~~---~--~~
You received this message because you are subscribed
I don't think it should be default as it is very slow. You have to
iterate over every child node in the DOM, extend it, and remove any
event listener. If your node has a lot of descendants, then you've just
added a ton of mostly useless overhead, as it is highly unlikely that
each of the des
Thanks for responses!
It seems to me that this behavior should be by default and if I not
want to clean event cache for the element and its storage it may be
better to have in the method an optional parameter which would say not
to clean event cache and elements storage.
Because almost in every
Hi,
There was a thread about that a while back, either here or over on the
Core mailing list. The idea did have its proponents, but I think most
of us felt that it was inappropriate overhead for the framework.
Since the application knows whether it has hooked events on the
element being removed
On 9 apr, 10:09, buda wrote:
> It's clear that Element.Remove should clean all event handlers and
> storage for the removed element and its children or am I wrong?
I am not sure if that would be ideal, however, the documentation
clearly states Element.remove removes the given element from the DO
11 matches
Mail list logo
