> I have noticed it too.
> Even if jQuery 1.3 is much faster than previous versions (as stated on
> their blog), animations are not smoother.
Do you have an example of which animations are causing problems and in
which browsers? Specific markup and CSS would certainly help.
--John
--~--~---
Hmm, ok. Unfortunately Google Code doesn't let you delete previous
releases so we'll just have to make sure it's not in the 1.3.1 bundle.
--John
On Wed, Jan 21, 2009 at 10:58 AM, David Zhou wrote:
>
> On Wed, Jan 21, 2009 at 10:50 AM, John Resig wrote:
>>
>&g
> when i ran into this issue, i repacked it using the current version of
> Packer for shits and giggles before sending Dean Edwards a bug report,
> and it worked just fine. what Packer version are you guys using, John?
We don't provide a packed version of jQuery - only minified.
--John
--~--~--
Well, considering that $('') is invalid
HTML (and $(...) only accepts valid HTML input) I think it's safe to
say that any output provided is not guaranteed to be correct.
--John
On Wed, Jan 21, 2009 at 10:38 AM, Enrique Meléndez Estrada
wrote:
>
> Hi,
> I don't know if this is an expected beh
> Should tickets for bugs caused by changing Object.prototype be left
> open for now? Maybe just leave a comment saying that for now we don't
> support this, but will at some time in the future?
That sounds reasonable - unless there's a master bug that we want to
mark them all as a duplicate of
Are you using the packed version of jQuery? It appears as if the
packer is somehow corrupting jQuery and causing some things to break -
try switching to the minified version. If that's not the case, do you
have an example?
--John
On Wed, Jan 21, 2009 at 8:13 AM, Diego wrote:
>
> Hi there,
>
>
> $('#foo').show(); // Plain display set as current.
> $('#foo').show('slow'); // Default animation using slow speed.
> $('#foo').show({animate:'fade'}); // Show using a fade animation at
> default speed.
> $('#foo').show({animate:'slidedown', speed:'fast'}); // Show using a
> slidedown animation
> If you were wondering what irked me a bit, it was primarily show/hide.
> $('#foo').hide(); does have the connotation of hiding something.
> However it always annoyed me how 'hide' was actually a very specific
> "scale diagonally to the upper left, and disappear". Rather than a
> simple 'hide me'
> Are we going to be able to pass parameters to the callback live
> function like we can with event callback functions?
At some point - this is something that I was looking to tackle in 1.3.2.
--John
--~--~-~--~~~---~--~~
You received this message because you are
This has already been resolved.
http://dev.jquery.com/ticket/3837
It'll land in jQuery 1.3.1 and is already in SVN.
--John
On Mon, Jan 19, 2009 at 8:04 PM, justint wrote:
>
> trying to move to 1.3,
> on page load I do something like
>
> $('div.thiselementisnotavailableyet>ul>li').each(...)
>
If you wish, you could file an enhancement bug here and we could check
in to it for a later release.
http://dev.jquery.com/newticket
This sounds like a reasonable addition.
--John
On Tue, Jan 20, 2009 at 6:41 AM, Már wrote:
>
>> I though the key was attaching the load event before the src?
>
> thanks John.
>
> Maybe change the wording a bit in the docs to say that they're only
> partially implemented or implemented for browsers X,Y,Z, rather than
> unsupported. As in my case, it's very helpful to know they're there,
> but not to expect them to work in IE.
Well, that's not true - they
> Updating the documentation on this, as John already did, is essential but do
> not clarify it entirely as it is now. In fact stopImediatePropagation
> depends on the order the events whore bound.
I've already removed the existing stopImediatePropagation hook that
existed for .live, it'll be com
Yes, they exist for compliant browsers.
--John
On Tue, Jan 20, 2009 at 2:09 PM, Leeoniya wrote:
>
>> It's both. Internet Explorer has problems with all of those events and
>> we wanted to be able to implement a smart solution that we could feel
>> good about - so until we can (likely for jQue
> interesting. this is ending up very similar to $.listen and $.delegate
> not being able to handle complex selectors, necessitating a $.is
> filter inside the callback to determine more complicated matches such
> as :eq, :has, etc.
Well, no, not exactly. This is a very specific case here: This u
Documentation updated:
http://docs.jquery.com/Events/live
Hope it's clearer now.
--John
On Tue, Jan 20, 2009 at 12:16 PM, John Resig wrote:
> Ok, so I looked at this issue more and I think the problem is being confused.
>
> Let's pretend that you only had one event bo
Ok, so I looked at this issue more and I think the problem is being confused.
Let's pretend that you only had one event bound:
> $("#list li").live('click', function(e) {
> alert('li clicked');
> });
That click will triggered if the li is clicked or if the a is clicked
- it doesn't matter.
Now
There was one ticket in which we were tracking this (but I don't
remember which, offhand). It is something that I'd like to get to
eventually, just not sure what sort of timeframe we're looking at
here.
--John
On Tue, Jan 20, 2009 at 10:12 AM, Scott González
wrote:
> I know there are plans to
nsparent to the user.
> When the 1.3.1 release is planed? I can later look into that and propose
> some patch and unit tests, but knowing the deadline would be great.
>
> []s,
> Iraê
>
>
> On Tue, Jan 20, 2009 at 11:54 AM, John Resig wrote:
>>
>> > So does tha
> So does that mean you can't add multiple listeners to an element using
> live() and avoid bubbling?
Sure you can - this seems to be a separate issue at play here.
--John
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Gr
Thanks for the report, I'll definitely look in to it.
--John
On Tue, Jan 20, 2009 at 2:18 AM, Walther wrote:
>
> Thanks, e.stopImmediatePropagation() works fine. But e.stopPropagation
> () and return false; doesn't.
>
> Sorry John, I don't have example url available.
>
> However I can post e
I like it - but the one tricky part is that .remove() is actually
functional beyond the simple .removeChild() call - it also removes any
bound event handlers and bound data from the elements (which is
something that this modified replaceWith would not do). That
functionality would need to stay int
What happens if you attach the load handler before you insert it into
the document?
--John
On Mon, Jan 19, 2009 at 12:23 PM, grigori wrote:
>
> Sample:
>
>
>
>
> var src="http://www.google.com/intl/en_com/im
Could you post this the jquery-ui-dev group, please? Thanks!
http://groups.google.com/group/jquery-ui-dev
--John
On Mon, Jan 19, 2009 at 2:28 PM, Jake Kronika, Webmaster, Gridline
Design & Development wrote:
> Hi,
>
> The following line, when added to the UI Tabs init() method, just prior to
Walther -
Do you have an example URL? It's kind of hard to determine from the
code that you've provided.
--John
On Mon, Jan 19, 2009 at 5:21 AM, Walther wrote:
>
> I am having a issue with the live event functionality in jQuery 1.3.
>
> Basically, I have a list with various options in this f
Yep - that's a duplicate of #3873 and has already been fixed!
--John
On Sat, Jan 17, 2009 at 5:26 PM, Karl Swedberg wrote:
> Hi Devs,
> Just wanted to call your attention to a rather lengthy thread on the
> jquery-en list:
> http://groups.google.com/group/jquery-en/browse_thread/thread/1c6403
> On Fri, Jan 16, 2009 at 2:40 PM, John Resig wrote:
>>
>> Thanks for the test case - I'll be looking in to it!
>>
>> --John
>>
>>
>>
>> On Fri, Jan 16, 2009 at 2:02 PM, Reinaldo JuniorZ wrote:
>>> It's easier to show a test case:
Could you file a ticket, please? (And be sure to mention that this
happens in both 1.2.6 and 1.3)
http://dev.jquery.com/newticket
--John
On Sat, Jan 17, 2009 at 1:42 PM, MarionNewlevant
wrote:
>
> $(' ').contents().length is 1 in firefox and safari, 0 in
> ie (6 & 7).
> (maybe hard to read: t
> Wow, that is sweet. For years I've had to deal with offsetWidth being
> 0 on hidden-by-parent elements, but never thought of using it as a
> feature!
Yeah, the tables have finally turned! We can use this stupid
bug/feature to our advantage.
--John
--~--~-~--~~~---~
You should mention this on the jquery-ui-dev mailing list, they should
be able to help you there.
http://groups.google.com/group/jquery-ui-dev
--John
On Sat, Jan 17, 2009 at 7:24 AM, jez wrote:
>
> Hi guys,
> I think the function _checkOffset is failing, in all browsers.
> Whenever open a dat
ontent with the alpha filter (I'd assume several filters do the
>> same, but alpha is what I've tested).
>>
>> I'll be sure to make a simple test case demonstrating the problem
>> tomorrow (late in Norway now), which affects both IE 6 and 7.
>>
>> --
ume several filters do the
> same, but alpha is what I've tested).
>
> I'll be sure to make a simple test case demonstrating the problem
> tomorrow (late in Norway now), which affects both IE 6 and 7.
>
> --
> Frode
>
> On Jan 16, 8:46 pm, John Resig wrote:
>&g
> Well, who has a return false inside of .each callback and is looking
> to use what it currently returns? Line 144 of core aka $.fn.each.
> doesn't need to change unless you are returning false inside of
> the .each.
>
> Actually, instead of returning just false, you could return whatever
> is s
Hmm, an interesting point. Do you have any test cases where the
negative effect of an alpha filter is readily available? (It would
help up to diagnose any problems if we were to implement this.)
If you can think of one then feel free to file a ticket!
http://dev.jquery.com/newticket
--John
On
> So, I've just tested this offset selector at IE6, IE7, FF3.0, Opera 9
> and Chrome. And it works as expected.
Cool, it certainly seems promising, at least. I think I'll tackle this
after 1.3.1 is landed.
--John
--~--~-~--~~~---~--~~
You received this message be
Thanks for the test case - I'll be looking in to it!
--John
On Fri, Jan 16, 2009 at 2:02 PM, Reinaldo JuniorZ wrote:
> It's easier to show a test case:
>
> 1) Open
> http://reinaldojunior.net/publico/test-bug-gt.html
>
> 2) Look the Firebug console.
>
> The problem:
>
> In jQuery 1.2.6
> $('.
>> Who was using it? and for what?
>
> ... ehr ... http://plugins.jquery.com/project/IfElseIfElse ...
>
> I rely on each returned behavior as filter and map, am I missing some
> change?
You're safe - you use $.fn.each, which we're not looking to change.
--John
--~--~-~--~~-
> The point was the $.each already had a return value and a certain
> amount of users could be relying on it.
That's what I'm trying to figure out: Who was using it? and for what?
I've honestly never seen anyone use the return value there. Granted we
may not be able to make this change (since we
is the one place.
>
> On Thu, Jan 15, 2009 at 6:48 PM, John Resig wrote:
>>
>> Where do we use the return value from $.each() (not to be confused
>> with $.fn.each)? I've never seen it used in that context (have for
>> $.map, naturally).
>>
>> --John
&
a space" (maybe copied
> from bind?). At the top is clear that binds only to one "Binds a handler to
> an event (like click) for all current ..."
>
> Thanks,
>
> Nano.
>
> On Thu, Jan 15, 2009 at 7:15 PM, John Resig wrote:
>>
>> > thx for your fas
> thx for your fast answer. Thought live is working exactly like bind
> except the cases you can find in the documentation.
>
> I've already made a ticket: http://dev.jquery.com/ticket/3885 can you
> plz delete or make it invalid. I will open a new enhancement request
> at: http://dev.jquery.com
I don't think it was ever stated that multiple live events worked (I
explicitly didn't mention them in the documentation since they weren't
implemented). I'm kind of surprised that anything worked in your test
case!
I may look to implement them for a future release. Would you be
interested in fil
its lack of name?
>
> On Thu, Jan 15, 2009 at 7:30 PM, John Resig wrote:
>>
>> Bug filed here: http://dev.jquery.com/ticket/3884
>>
>> --John
>>
>>
>>
>> On Thu, Jan 15, 2009 at 7:29 PM, John Resig wrote:
>>> Erm. Good point. Time t
Bug filed here: http://dev.jquery.com/ticket/3884
--John
On Thu, Jan 15, 2009 at 7:29 PM, John Resig wrote:
> Erm. Good point. Time to fix it!
>
> --John
>
>
>
> On Thu, Jan 15, 2009 at 5:40 PM, Nano. wrote:
>>
>> Hi,
>>
>> If v1.3 has change
> $(document).ready(function(){
>$("input[name!='newsletter']").next().text(" is not newsletter");
> });
>
>
>
>
>
>
>name?
>
>
>
>name?
>
>
>
>name?
>
>
>
>
ter. As I
> said I just recently started experimenting with jQuery and thus use
> the documentation a lot to find my way around jQuery. But I'd bet
> you're probably busy revising it after the recent 1.3 update anyway.
>
> — Frode
>
> On Jan 15, 5:11 pm, John Resig wrote
ng it would
> break old code (even our own).
> Also.. I think we should not mess with $.each, as it's the most
> frequently called function all over the framework.
>
> On Thu, Jan 15, 2009 at 6:14 PM, John Resig wrote:
>>
>> I think there was a slight mis-commun
> It's not a bug, is() always returns true for unsupported selectors.
> Complex selectors like you're using are not supported.
That's no longer the case - in jQuery 1.3 .is() now supports complex
selectors (it was in the release notes, yesterday).
I'll need to review this test case but it's poss
> Removal of inline events via unbind() could be added to the core, it's
> very useful. I guess a check for .attr('on'+event) wouldn't be much
> overhead. Where do we file enhancement proposals?
We could probably do it for .unbind("click").
Just file it in the bug tracker:
http://dev.jquery.com/
gt;
>> > Ah... sort of an (inverted) detect/any function
>>
>> > Ok, why not :)
>>
>> > On Thu, Dec 18, 2008 at 11:58 AM, John Resig wrote:
>>
>> > >> Isn't that what $.map does ?
>>
>> > > Not r
Two quick things:
1) This selector isn't valid: $("div span[offsetWidth>0]"); (There's
no > in jQuery attribute selectors).
2) I really like the idea of checking the offsetWidth - that seems
much faster than what we're doing right now - and seems relatively
painless.
Could you file a bug on usi
> If an event is defined in a tag, say ,
> then $(img).unbind() has no effect on the onclick attribute. I have
> to go in an set the onclick="".
>
> Is this expected behavior?
I'm not sure. Since it wasn't an event that we bound I'm not sure what
the protocol would be for removing it (we'd have
> afaik: safari has are issues with case sensitivity and selectors when in
> quirks mode.
I'm going to try and fix this - but for the most part code is just
more likely to work better in standards mode, we might have to apply
more workarounds (and, thus, take a slower code path) in order to make
I just created a ticket:
http://dev.jquery.com/ticket/3878
--John
On Thu, Jan 15, 2009 at 9:50 AM, John Resig wrote:
> Dave -
>
> It has not been filed - could you do so in the jQuery bug tracker? Thanks.
> http://dev.jquery.com/newticket
>
> --John
>
>
>
> O
On this point I disagree.
The previous version was equal to:
li:not([class=zoom])
The current version is equal to:
li[class]:not([class=zoom])
This change came about after discussing it over with the MochiKit team
(since they use the same selector engine as us) and I have to agree
with their im
a single-quote error (should be double-quoted) after the second 'p'.
>>
>> Diogo
>>
>>
>>
>> On Thu, Jan 15, 2009 at 11:23 AM, John Resig wrote:
>>
>> > As I mentioned in another thread, this looks like a bug and should
>> > pro
t;
> http://media.nodnod.net/eq.html
>
> Note that $('table tr:eq(36)') gives none while $('table tr:eq(5)')
> gives 2. One for each table.
>
> On Thu, Jan 15, 2009 at 12:31 AM, John Resig wrote:
>>
>> Hmm - yep - definitely looks like an issue here,
onsidering the
> latest WebKit build is truly case-insensitive. Can we detect this
> condition and toLowerCase the query?
> -Sidney
>
> On Jan 14, 2009, at 12:39 AM, John Resig wrote:
>
>>
>> Something finally struck me about what you said (sorry, it's late
>
9:
>> > for ( var i = 0; !curLoop[i]; i++ ){}
>> > in Firefox 3. WebKit does not have the same error.
>>
>> > Same page worked fine in 1.2.6 and in 1.3b2. I'll try to get a
>> > reduction/testcase later on tonight (working under a deadline right
&
As I mentioned in another thread, this looks like a bug and should
probably be filed. Thanks!
--John
On Thu, Jan 15, 2009 at 6:43 AM, David Hulbert wrote:
>
> I get:
>
> "A script on this page may be busy, or it may have stopped responding.
> You can stop the script now, open the script in th
David -
That looks like a separate issue - could you file a bug? Thanks!
--John
On Thu, Jan 15, 2009 at 5:18 AM, David Hulbert wrote:
>
> Is this issue related to this?
>
> $('div:has("p+p")') // goes into infinite loop with this HTML
> 1
>
> Test case: http://jsbin.com/atiha/edit
>
> Or sho
Hmm - yep - definitely looks like an issue here, will check in to it, thanks!
--John
On Wed, Jan 14, 2009 at 9:27 PM, jquery.redsqu...@googlemail.com
wrote:
>
> I think there is an issue with :eq().
>
> Demo test case http://jsbin.com/omobe
>
> >
>
--~--~-~--~~~--
Do you have an example page where this occurs?
--John
On Wed, Jan 14, 2009 at 4:30 PM, Nesto wrote:
>
> I tried using the timeout option on $.ajax and it just didn't seem to
> work.
>
> I think I tracked it down, since xhr gets set to null in
> onreadystatechange( "timeout" );,
>
> if ( xhr )
from:
>>
>> http://code.google.com/p/jqueryjs/
>>
>> Are you using the right version of jquery?
>>
>>
>>
>> On Wed, Jan 14, 2009 at 4:15 PM, John Resig wrote:
>>
>> > Can you file a bug in the bug tracker? Thanks.
>> >http://de
Do you have a test page demonstrating the issue? It would help us to
diagnose the problem.
--John
On Wed, Jan 14, 2009 at 2:14 PM, matt wrote:
>
> I cant seem to set the value of any select elements using val. Input
> type=text is working fine.
>
> So I have something like:
>$('#usa_r
Ariel -
> http://docs.jquery.com/Release:jQuery_1.3#Effects
>
> Animations with no duration now behave differently than in 1.2.6.
> That's why, it's not a regression, it's a feature.
It definitely looks like there's something else going on here, though.
Just because the animation happens instant
Can you file a bug in the bug tracker? Thanks.
http://dev.jquery.com/
--John
On Wed, Jan 14, 2009 at 4:08 PM, Leeoniya wrote:
>
> this is a definitely a show stopper for me. just tested in ie7,
> chrome, FF nightly, opera. : (
>
>
> On Jan 14, 2:54 pm, Leeoniya wrote:
>> .val() now returns u
> For example, opacity. The "support" check is whether style.opacity
> works correctly, but if it doesn't then it is _assumed_ that using
> alpha is the fix. This is the wrong logic. Instead, you should check
> specifically for whether alpha is required. A browser may exist (in
> theory) that does
tabbable elements and doesnt need DOM traversal on
>> each tab press. the nextest feature would definitely be intensive.
>>
>> ...have some more thinking to do on a reasonable compromise. caffeine
>> shall aid this process.
>> Leon
>>
>> On Jan 14, 10:15 am,
Well, my guess is that you're testing it in Firefox - it works there
but doesn't work in IE. We're going to be adding in IE support for
change very soon in an upcoming 1.3.x update.
--John
On Wed, Jan 14, 2009 at 11:22 AM, James Hughes wrote:
>
> Hello,
>
> Sorry of this comes across as a sil
> i've been using chains like this all over my webapp:
>
> $(this).parents("li:eq(0)")
>
> it seems that closest is a direct replacement for this and a
> functional equiv of
>
> $(this).closest("li").
It's almost equivalent to that. There's the possibility that if 'this'
is an li element that it
Hey Everyone -
jQuery 1.3 is out! Full details here:
http://blog.jquery.com/2009/01/14/jquery-13-and-the-jquery-foundation/
Happy 3rd Birthday, jQuery!
--John
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuer
Something finally struck me about what you said (sorry, it's late
here) - it fails only in Safari. Safari uses the native
querySelectorAll exclusively - we don't do anything.
I took your page and put it online and it fails (as you expected):
http://ejohn.org/files/jquery1.3/safari.html
But then
Inside your click handler:
$(this).parent().next();
In the future a question like this would be better suited for this mailing list:
http://groups.google.com/group/jquery-en
--John
On Tue, Jan 13, 2009 at 11:56 PM, Ajay wrote:
>
> Hi,
>
> I have a requirement in which I need to access the ne
> I guess that mean 1.3 is already cut final? I was trying to get this
> in ASAP to get it in 1.3 -- I can reproduce it every time, and I'd
> imagine this one could do some serious damage out there in the wild...
Yeah, 1.3 is final. We'll be doing 1.3.1 within the week to catch any
straggling bu
Huh, that's an odd one - could you file a ticket, please?
http://dev.jquery.com/
I'll check up on it and get it in to 1.3.1.
--John
On Tue, Jan 13, 2009 at 9:04 PM, Adam Fisk wrote:
>
> I'm seeing very odd behavior in Safari with selecting class names that
> include upper case characters. I
Opera also has attachEvent, so no.
--John
On Tue, Jan 13, 2009 at 1:06 PM, Ariel Flesler wrote:
>
> Isn't this good enough ?
>
> IE = !!document.attachEvent;
>
> On Tue, Jan 13, 2009 at 3:00 PM, kangax wrote:
>>
>> On Jan 13, 10:17 am, Diego Perini wrote:
>>> Kanagax,
>>> agree with you abo
For this reason we gave you all the tools that you need to do your
specific delegation.
For example:
$("#mycontainer").mousemove(function(e){
$(e.target).closest("td").each(function(){
// do something
});
});
--John
On Tue, Jan 13, 2009 at 11:47 AM, Leeoniya wrote:
>
> I may soon ne
ng's working great in FF (as long as there are no spaces in
> attribute selectors).
> I updated my test page to include both
> issues: http://jquery.glyphix.com/1.3/
> _
> Brad Brizendine
> CTO, Glyphix http://www.glyphix.com/
>
>
&g
>> just tested the 1.3rc2, and it seems the attribute selector doesn't
>> work when selecting the anchor links:
>>
>> $('a[href^=#]')
>>
>> returns zero objects.
>
> I can duplicate this - has to do with how href attributes are
> determined, I'll see if I can fix it.
Just added a fix for this:
ht
Fixed.
http://github.com/jeresig/sizzle/commit/0194670274ebeec815dc99a28d5dec3794dec817
Will push to trunk soon.
--John
On Tue, Jan 13, 2009 at 9:35 AM, John Resig wrote:
> After some testing it appears as if the following works:
> jQuery("> *:eq(0)", context)
>
&g
After some testing it appears as if the following works:
jQuery("> *:eq(0)", context)
While the follow fails:
jQuery("> :eq(0)", context)
Seems like it should be easy enough to fix, will check in to it.
--John
On Tue, Jan 13, 2009 at 6:09 AM, Paul Bakaus wrote:
> Hey guys,
>
> when investig
> just tested the 1.3rc2, and it seems the attribute selector doesn't
> work when selecting the anchor links:
>
> $('a[href^=#]')
>
> returns zero objects.
I can duplicate this - has to do with how href attributes are
determined, I'll see if I can fix it.
> another very weird bug:
>
> $('*').siz
> $('.myClass').find(':first-child')
> use this instead:
> $('.myClass').children(':first')
The difference between these two selectors is that the first will
match all *descendant* elements which are the first child of their
parent. That could be quite a few elements.
Whereas the second one will
Thanks for the test case! I agree that the error should probably
become a little more useful. Could you file a bug on this? Thanks!
http://dev.jquery.com/
--John
On Tue, Jan 13, 2009 at 7:45 AM, ajp wrote:
>
> I should add that I'm aware with 1.3 the correct response should be
> "Syntax error
> the only way to delegate without specifying a container would probably
> be to implicitly bind any event handlers to or , is that
> what happens in $.live?
Yes. .live() binds on document and captures bubbled events.
--John
--~--~-~--~~~---~--~~
You received th
> Another one: http://jquery.glyphix.com/1.3/
> In ie7, I get:
>
> Line 2159: "object doesn't support this property or method"
> Line 29: "object doesn't support this property or method"
Hmm, ok - this is due to expandos being assigned to an XML node. I'll
check in to this. Thanks for the test ca
Hey Everyone -
jQuery 1.3rc2 is ready. This means that 1.3 is effectively finished
barring a horrible bug between now and the final release on Wednesday
(the 14th).
You can grab the source here:
http://code.jquery.com/jquery-1.3rc2.js
Please let me know, personally, if you find some bad new bug
Just to clarify: $.browser is not being removed in 1.3 - and not for
the foreseeable future - but it is deprecated.
--John
On Mon, Jan 12, 2009 at 3:04 PM, Dan G. Switzer, II
wrote:
>
> Boy, I'm not looking forward to $.browser.msie being removed. I use
> that all the time to add class defini
Yeah, I figured that's what was happening. An older version of Sizzle
used caching to improve performance - but that ended up negatively
affecting the performance of normal DOM manipulation, so it was
removed.
No need to upload your suite - I can see what was happening now! But
thanks for the cla
What version of Sizzle are you using? What version of SlickSpeed? Do
you have a URL somewhere?
--John
On Mon, Jan 12, 2009 at 3:57 AM, lhwpa...@googlemail.com
wrote:
>
> mh i have nearly the same issue on ff 3.05 and ff 2.0.20.
>
> i have tested it against single-sizzle (and other frameworks)
Yep - I've got that one on the list - thanks!
--John
On Mon, Jan 12, 2009 at 6:19 AM, emelendez wrote:
>
> Hi,
> I have 3 html TABLEs in my DOM
>
> $("table:not(:first)").length()
>
> gave me 2 (correct) tables in 1.2.6
> gives me 5(???) tables in 1.3rc1
>
> also, doesn't work the version:
>
> does this mean it'll work in the 1.3 final? : \ (nervous)
Yes, a fix for this bug will be in the final release.
--John
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this g
>> jQuery 1.3rc1 is ready. This means that 1.3 is effectively finished
>> barring a horrible bug between now and the final release on Wednesday
>
> That's great news. For those of us who haven't been following recent
> development, are there any release notes available?
Nope - but there will be
Hey Everyone -
jQuery 1.3rc1 is ready. This means that 1.3 is effectively finished
barring a horrible bug between now and the final release on Wednesday
(the 14th).
You can grab the source here:
http://code.jquery.com/jquery-1.3rc1.js
Please let me know, personally, if you find some bad new bug
pm, Briz wrote:
>> Thanks, I was hoping it was helpful.
>>
>> On Tue, Jan 6, 2009 at 10:07 AM, John Resig wrote:
>>
>> > Thanks for pulling this together - I'm making a note of it!
>>
>> > Oh, and great test case, by the way :-) It's grea
Interesting. I like the first one especially. Could you file a bug on
these? I'd definitely like to look into them later, but probably not
in time for 1.3.
--John
On Sun, Jan 11, 2009 at 3:42 AM, Cloudream wrote:
>
> 1. remove/re-add all original CSS class
>
> implement: save original class t
> Not yet, looks like you missed the actual fix for #3796 :)
>
> This is the end of the current POS regex:
> (?:[^-]|$)
>
> The problem is that it matches then removes ":odd:"
> from ":odd:first". Inserting a colon next to the hyphen would solve
> this.
Actually, just turned the last part into a
orm element(or probably any
>> element) with a name attribute that has a value of id. If there is anything
>> else you need to reproduce this bug, just let me know.
>>
>> Also tickethttp://dev.jquery.com/ticket/2990seems to be what i am
>> experiencing but there has bee
This issue should be resolved now.
--John
On Tue, Jan 6, 2009 at 1:33 PM, Balazs Endresz wrote:
>
> Regarding the other one, $('li').not(':odd:first'):
> http://dev.jquery.com/ticket/3796
>
> On Jan 6, 7:07 pm, "John Resig" wrote:
>> Th
701 - 800 of 1010 matches
Mail list logo
