To ensure order and uniqueness with XML and non current documents too,
we have to ensure that the NodeList "allSort" is the correct one.
Maybe something like this:
function sortNodes( array ) {
if ( array.length === 0 )
return;
if ( allSort && allSort._document !=
That too is one of the many things that has bothered me. At work we
actually use a wrapper function which will try to make use of any one of
the existing json libraries on json.org, or native JSON if available,
basically if it can find a JSON parser loaded into the page it'll try to
use it ins
With the advent of native JSON support in browsers forthcoming, should
jQuery.support check for the existence of the JSON obj and use it as
the preferred way of parsing JSON whenever the library needs to do
so? This would have the added benefit of leveraging json2.js for
users who already have th
> Previously, elements with visibility:hidden were not :visible, but now
> they are (tested in IE6,FF3). Was this an intentional change?
Yes. Previously bugs would occur with methods like height/width,
hide/show, and animate (which only operated on the display property)
but the :visible and :hidd
Depends how many bugs are spotted - hopefully not many.
--John
On Mon, Feb 16, 2009 at 5:36 PM, mike.helgeson wrote:
>
> How many days, do you reckon, from alpha until release for 1.3.2?
>
> On Feb 16, 5:30 pm, John Resig wrote:
>> It's not supported but a swtch to a typeof check seems simpl
On Feb 16, 12:31 pm, John Resig wrote:
> There were some logic changes ... how :visible/:hidden work
Previously, elements with visibility:hidden were not :visible, but now
they are (tested in IE6,FF3). Was this an intentional change?
Matt Kruse
--~--~-~--~~~---~--~-
- 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
Do you still have those speed tests for this around. I'm more curious why it
speeds things up than anything else. I understand why it speeds things up in
hide... just not understanding how we are gaining any performance in show.
--
Brandon Aaron
On Mon, Feb 16, 2009 at 4:26 PM, John Resig wrote:
How many days, do you reckon, from alpha until release for 1.3.2?
On Feb 16, 5:30 pm, John Resig wrote:
> It's not supported but a swtch to a typeof check seems simple enough.
> Thanks for the tip.
>
> --John
>
> On 2/16/09, Diego Perini wrote:
>
>
>
>
>
> > John,
> > thank you for the nice add
It's not supported but a swtch to a typeof check seems simple enough.
Thanks for the tip.
--John
On 2/16/09, Diego Perini wrote:
>
> John,
> thank you for the nice additions and fixes, the "document order" is
> really welcome :-)
>
> Just a minor thing I noticed in the new code source is about
The dual loop is actually a huge speed-up. If we set the display
inside the first loop (and then check the computed display of the next
element) this causes a fresh reflow of the page. For every single
element that we show/hide. Last check this is giving us a 2x speedup
(even with the extra loop a
Whoops... spoke to soon. The show method is throwing errors in IE 6. The
main issue is that IE 6 doesn't like setting this[i].style.display to
undefined. Second, it looks like the second for loop is sitting within the
first for loop when I believe the intention was to have them separate, not
nested
John,
thank you for the nice additions and fixes, the "document order" is
really welcome :-)
Just a minor thing I noticed in the new code source is about older
Opera (probably 9.27 and older). Opera have implemented the
"sourceIndex" property too but it starts at index "0" for the
documentElement
No issues here.
--
Brandon Aaron
On Mon, Feb 16, 2009 at 12:31 PM, John Resig wrote:
>
> Hey Everyone -
>
> Just finished up the last ticket for 1.3.2 and wanted to throw a copy
> out for people to try:
> http://code.jquery.com/nightlies/jquery-2009-02-16.js
>
> Please let me know if anything i
Hey Everyone -
Just finished up the last ticket for 1.3.2 and wanted to throw a copy
out for people to try:
http://code.jquery.com/nightlies/jquery-2009-02-16.js
Please let me know if anything is breaking from 1.3.1 -> 1.3.2.
There were some logic changes - specifically with cloning in IE (lots
Taken care of - thanks!
--John
On Mon, Feb 16, 2009 at 11:54 AM, David Zhou wrote:
>
> http://dev.jquery.com/ticket/4165 -- sounds like he needed to use live events.
> http://dev.jquery.com/ticket/4159 -- invalid
> http://dev.jquery.com/ticket/4158 -- patch of fix discovered by initjh
>
> Tha
http://dev.jquery.com/ticket/4165 -- sounds like he needed to use live events.
http://dev.jquery.com/ticket/4159 -- invalid
http://dev.jquery.com/ticket/4158 -- patch of fix discovered by initjh
Thanks!
-- dz
--~--~-~--~~~---~--~~
You received this message becaus
I agree. This would be really helpful.
On 10 Feb., 15:27, Strykker wrote:
> After struggling with obtaining/creating and attaching ranges in a
> jQuery cross-browser application (most problems on safari/web-kit), I
> think it would be very nice if jQuery provided a standardized way of
> dealing
Yeah, so I've been banging my head against the wall for multiple hours
because my website in development working perfectly in Safari and
Firefox and works like crap in IE (6 & 7). I finally narrowed the
problem down to IE caching my images, and now this website helped me
realize IE doesn't fire th
> So, if I understand you, the third argument is exposed to the API but
> not like an set that will be filled with additional query, but like an
> simple array which the new elements will be simply appended.
> So if the user would use the third argument, later, he will eventually
> resort and remo
So, if I understand you, the third argument is exposed to the API but
not like an set that will be filled with additional query, but like an
simple array which the new elements will be simply appended.
So if the user would use the third argument, later, he will eventually
resort and removes the du
> I know, but adding other elements to the results (given as argument)
> will probably make the results array unsorted (even with duplicates).
I think there's a disconnect here. When there isn't multiple arguments
(e.g "a.foo") there are no duplicates or sorting problems - that's
implicit in the
Maybe I was not clear. I don't think it is wrong to live results
unsorted if given as argument (if it was planed), but then we can take
this in consideration to do optimizations...
On Feb 16, 2:53 pm, Robert Katić wrote:
> I know, but adding other elements to the results (given as argument)
> wi
I know, but adding other elements to the results (given as argument)
will probably make the results array unsorted (even with duplicates).
On Feb 16, 2:47 pm, John Resig wrote:
> > Hm, how implemented, usage of the third argument would not guarantee
> > that the results will be sorted.
> > Take
> Hm, how implemented, usage of the third argument would not guarantee
> that the results will be sorted.
> Take for example: Sizzle('foo.barr', null, anArray) - there is no
> extra selector, so no sorting too.
That's fine - since selectors that don't have a comma in them are
already in document
Hm, how implemented, usage of the third argument would not guarantee
that the results will be sorted.
Take for example: Sizzle('foo.barr', null, anArray) - there is no
extra selector, so no sorting too.
On Feb 16, 2:22 pm, John Resig wrote:
> > If I am right, with this implementation, with "a, b
> If I am right, with this implementation, with "a, b, c" the results
> will be sorted twice.
> If so, would it be enough to replace line 115 with this one?
>
> if ( sortOrder && !arguments[2] ) {
>
> Maybe it looks dirty... but anyway sorting is not an cheap
> operation...
That wouldn't be suffi
Ah - that's neat - thanks Mark
On 16 Feb, 10:33, Mark Gibson wrote:
> .live registers all handlers on document, so in this case would have
> to filter all click events.
> For this case you may be better off handling this at the grid level
> and making use of .closest:
>
> $(".grid").bind('click'
.live registers all handlers on document, so in this case would have
to filter all click events.
For this case you may be better off handling this at the grid level
and making use of .closest:
$(".grid").bind('click', function(ev) {
var sq = $(ev.target).closest('.sq');
...
});
On Feb 15
If I am right, with this implementation, with "a, b, c" the results
will be sorted twice.
If so, would it be enough to replace line 115 with this one?
if ( sortOrder && !arguments[2] ) {
Maybe it looks dirty... but anyway sorting is not an cheap
operation...
On Feb 14, 6:14 pm, John Resig wro
30 matches
Mail list logo
