Andrea,
> The snippet you blamed for free, the Internet Explorer Scope Resolution
I never mentioned the article. I referenced your snippet in this
mailing list. I don't know where you got that from.
> What am I talking about, quite simple. If you understood IE scope
> resolution, and again yo
Sorry my previous comment had line-break issues.
Here is my reply again.
Andrea,
> quite unfair man ... first of all the warning was for this suggested code:
It's perfectly fair. I linked to your exact post with the snippet
(http://bit.ly/3ePh0T)
> and I chalenge you to find a leak there where
Andrea,
> quite unfair man ... first of all the warning was for this suggested code:
It's perfectly fair. I linked to your exact post with the snippet
(http://bit.ly/3ePh0T)
> and I chalenge you to find a leak there where ext is the only name in that
scope.
Just because your 1 time leak may be
I just wanted to point out that the pattern proposed by Andrea (http://
bit.ly/3ePh0T)
does in fact leak memory and will cause Safari 2 to throw a parse
error.
First download `Process Explorer` (http://bit.ly/2QxebL) then go to
this page in IE:
http://dl.getdropbox.com/u/513327/andrea/leak.html
Hi Oleg,
Andrea is right there is a cost/benefit to caching and it's not a
magic cure-all for selector engine performance.
NWMatcher uses result caching only when it recognizes the benefit is
greater than the cost. For example NWMatcher only caches
when mutation events are supported, querySelecto
Just to re-enforce what kangax said at least Opera 9.25 and 10 will
not throw an error but use the function declaration intended for IE
only in the code proposed by Andrea.
http://groups.google.com/group/jquery-dev/msg/105e37aa9c979a37
Example:
http://dl.getdropbox.com/u/513327/bug/andrea_decla
I saw this with Prototype, I don't consider it a leak, frames take up
a certain about of memory, the more frames the more it consumes.
When you refresh page the memory should be released. If not, then its
a leak.
--~--~-~--~~~---~--~~
You received this message becau
* It effects IE 7 too (fixed in IE8)
--~--~-~--~~~---~--~~
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 em
@John Resig - Your try-finally block fails in IE6 because of this bug:
http://webbugtrack.blogspot.com/2007/11/bug-184-catch-to-try-catch-finally-in.html
Also it doesn't appear to break at the correct spot either.
http://dl.getdropbox.com/u/513327/handler-fail.png
- JDD
--~--~-~--~
Hello Nothize,
Modifying Object.prototype will cause more than problems with jQuery.
Anything that for-in iterates over an object will be affected.
json2 follows the ECMA 3.1 draft, and uses native JSON api where
available, so its a pretty win win solution.
Trying to back in a patch for this iss
There is no need to cache regexp literals (ex: /foo/).
http://bclary.com/2004/11/07/#a-7.8.5
"The object is created before evaluation of the containing program or
function begins. Evaluation of the literal produces a reference to
that object; it does not create a new object."
- JDD
--~--~--
I think in cases where something is visibly wrong, like with IE6
select element, and there is no capability check possible (AFAIK)
then
it is ok to use the browser sniff. The iframes addition isn't a show
stopper for other browsers so
at worst if the sniff is wrong you get an iframe when not need
Sizzle is John's creation so it just makes sense that jQuery (and
others) use that engine.
Peppy is similar to Sizzle and can be configured (by commenting out
blocks of code) to work with dynamic content.
I believe the SlickSpeed tests only run the CSS queries once per
framework so there probably
13 matches
Mail list logo
