Good catch, fixed!
--John
On Thu, Jan 15, 2009 at 10:23 PM, Nano. wrote:
> Hi Guys,
>
> I think there is a typo in the documentation.
>
> http://docs.jquery.com/Events/live#typefn at the Arguments section for the
> type it says "One or more event types separated by a space" (maybe copied
> fr
Hi Guys,
I think there is a typo in the documentation.
http://docs.jquery.com/Events/live#typefn at the Arguments section for the
type it says "One or more event types separated by a space" (maybe copied
from bind?). At the top is clear that binds only to one "Binds a handler to
an event (like cl
Just started the new ticket while getting your answer. :D
Thanks again for your fast responses.
with regards
alx
On Jan 16, 4:15 am, John Resig wrote:
> > thx for your fast answer. Thought live is working exactly like bind
> > except the cases you can find in the documentation.
>
> > I've al
> 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
Hi John,
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
Damn. I'm always outdated! Sorry for the confusion, and thanks for
coming in :]
On Jan 15, 6:29 pm, John Resig wrote:
> > 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 .
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
While palying around with the latest svn build of jquery I noticed
that .live is don't triggering the first assigned event, if you pass a
list of events to the first argument like you can do so with bind.
Every event is triggered except the first assigned even if you pass
all the supported events
UI 1.5.3 will never work with jQuery 1.3. That's the whole point.
On Jan 15, 3:44 pm, SwimDrewid wrote:
> I am finding this to be true with 1.5.3 as well -- I am unable to
> trigger the 'receive' handler in a sort method
>
> On Jan 15, 8:10 am, lrbabe wrote:
>
> > I'm not very certain about th
Yes, David is right.
Sorry for the confusion.
Nano.
On Jan 15, 4:44 pm, John Resig wrote:
> Uhh, yeah - you're right. It's been a long week :-P
>
> --John
>
> On Thu, Jan 15, 2009 at 7:38 PM, David Zhou wrote:
> > Why is that a bug?
>
> > If 1.3 matches only elements that have the specified a
Uhh, yeah - you're right. It's been a long week :-P
--John
On Thu, Jan 15, 2009 at 7:38 PM, David Zhou wrote:
> Why is that a bug?
>
> If 1.3 matches only elements that have the specified attribute,
> shouldn't the second radio remain as "name?" due to its lack of name?
>
> On Thu, Jan 15, 20
Why is that a bug?
If 1.3 matches only elements that have the specified attribute,
shouldn't the second radio remain as "name?" due to 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, 200
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 changed, why the demo on
>> http://docs.jquery.com/Sele
Erm. Good point. Time to fix it!
--John
On Thu, Jan 15, 2009 at 5:40 PM, Nano. wrote:
>
> Hi,
>
> If v1.3 has changed, why the demo on
> http://docs.jquery.com/Selectors/attributeNotEqual
> has the 2nd input not changed to " is not newsletter " (2nd input has
> no name attribute).
>
> Output
Hi,
If v1.3 has changed, why the demo on
http://docs.jquery.com/Selectors/attributeNotEqual
has the 2nd input not changed to " is not newsletter " (2nd input has
no name attribute).
Output:
name?
name?
is not newsletter
Source code:
=
http://www.w3.org/TR/html4/loose.dtd";>
http://
Good call - just updated the docs:
http://docs.jquery.com/Selectors/attributeNotEqual
--John
On Thu, Jan 15, 2009 at 4:49 PM, prefect wrote:
>
> Ah, I see. That seems like a good decision. Then my only minor point
> would be to update the documentation of the [attr!=value] filter. As I
> said
Ah, I see. That seems like a good decision. Then my only minor point
would be to update the documentation of the [attr!=value] filter. 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 rev
I am finding this to be true with 1.5.3 as well -- I am unable to
trigger the 'receive' handler in a sort method
On Jan 15, 8:10 am, lrbabe wrote:
> I'm not very certain about the origin of this problem, but it appears
> that when using the last release candidate of jQuery-UI with the last
> off
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
On Thu, Jan 15, 2009 at 3:44 PM, Ariel Flesler wrote:
>
> I agree with Dave, $.each already returns data so changing it would
> break
Perhaps tacking on a 'returnValue' on to the object that is returned.. that
is however quite smelly.
On Thu, Jan 15, 2009 at 3:44 PM, Ariel Flesler wrote:
>
> I agree with Dave, $.each already returns data so changing it would
> break old code (even our own).
> Also.. I think we should not mess
I agree with Dave, $.each already returns data so changing 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
> 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/
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?
On Jan 15, 5:46 pm, John Resig wrote:
> > If an event is defined in a tag, say ,
> > then $(img).unbind() h
It's not a bug, is() always returns true for unsupported selectors.
Complex selectors like you're using are not supported.
And you can't do that with the :even or :odd pseudo-selectors, as $
(this) gives you a single element which is always "even".
$(".stripe tr").click( function(){
if($(this
Let me put it here because this was opened a month ago, moreover it's
unassigned:
http://dev.jquery.com/ticket/3729
Now attributes seem to have some surplus of backslashes.
On Jan 15, 8:41 pm, John Resig wrote:
> > afaik: safari has are issues with case sensitivity and selectors when in
> > quir
I think there was a slight mis-communication, I'll open it back up.
--John
On Thu, Jan 15, 2009 at 3:11 PM, ajpiano wrote:
>
> http://dev.jquery.com/ticket/3877
>
> The response ths ticket got isn't what I would have expected it to get
> based on the reactions in this thread? Wha happen?
>
>
http://dev.jquery.com/ticket/3877
The response ths ticket got isn't what I would have expected it to get
based on the reactions in this thread? Wha happen?
--adam
On Dec 18 2008, 8:11 pm, oliver wrote:
> I suppose this is only changing thereturnvalue of $.each, not $
> ([elem]).each(), correc
I have had a few projects where the HTML was not 100% under my own control
and couldn't run in standards mode.
However, in those situations, I did NOT promise the client full
compatibility across all major browsers.
If this was an issue with the client, I demanded either control over the
HTML or
Suggestion: to create a plugin or new method to support native event
handlers (I don't know if the new Event class supports them, though), for
the sake of performance.
Diogo
On Thu, Jan 15, 2009 at 5:46 PM, John Resig wrote:
>
> > If an event is defined in a tag, say ,
> > then $(img).unbind()
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
afaik: safari has are issues with case sensitivity and selectors when in
quirks mode.
On Thu, Jan 15, 2009 at 2:32 PM, Matt wrote:
>
> Could anyone explain this statement on the wiki page?
>
> "You should always be sure to run your page in standards mode. There
> are
> known issues with methods
Could anyone explain this statement on the wiki page?
"You should always be sure to run your page in standards mode. There
are
known issues with methods not working correctly in quirks
mode (including errors in the selector engine in Safari). "
Is there a list of the known issues somewhere? (I b
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?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
The concept is simple: to find the elements that are visible at the
screen.
But by using the :visible selector, it verify only the element itself,
so if a parent element is hidden, the child is still considered as
visible.
Here's an example markup:
TEST
If we use this selector:
$("div:visible");
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
>
>
>
> On Thu, Jan 15, 2009 at 9:43 AM, Da
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
The documentation for the [attr!=value] filter reads: "Matches
elements that either don't have the specified attribute or do have the
specified attribute but not with a certain value."
In 1.2.6 $("li[class!='zoom']") would give me both LI elements without
a class attribute and those with a class
Dave -
It has not been filed - could you do so in the jQuery bug tracker? Thanks.
http://dev.jquery.com/newticket
--John
On Thu, Jan 15, 2009 at 9:43 AM, David Hulbert wrote:
>
> The message is wrong, but the test was right:
> $('div:has("p+p")')
>
> Has the bug already been filed then?
> Is
I've filed a ticket for the :eq() issue: http://dev.jquery.com/ticket/3873
--John
On Thu, Jan 15, 2009 at 2:07 AM, David Zhou wrote:
>
> It looks like a bug in Sizzle -- specifically, when applying filters,
> it's applying to the two tables separately.
>
> See:
>
> http://media.nodnod.net/eq.
The message is wrong, but the test was right:
$('div:has("p+p")')
Has the bug already been filed then?
Is it a bug with jQuery or Sizzle?
Thanks,
Dave
On Jan 15, 1:28 pm, "Diogo Baeder" wrote:
> Hmmm... the code is exactly as written in the test? Because
> $('div:has("p+p')')
> has a single-q
Hello Jörn,
Nop, parent return the only one direct ancestor of a element, and so
can return set of element corresponding to each direct ancestor of
each element matched.
In my example the LI can't be the direct ancestor of the other LI.
On 15 jan, 12:40, Jörn Zaefferer
wrote:
> Isn't that paren
Just to follow-up, this is the bug where we're tracking the issue:
http://dev.jquery.com/ticket/3840
--John
On Wed, Jan 14, 2009 at 12:54 AM, Sidney San Martín wrote:
>
> I saw this thread a half hour ago or so and decided to take a poke at
> it. Took me a while to find the querySelectorAll b
Donald -
It looks like a bug has been filed here:
http://dev.jquery.com/ticket/3837
Checking in to it - thanks!
--John
On Tue, Jan 13, 2009 at 4:21 PM, Donald @ White Whale
wrote:
>
> Okay, so I was right the first time. It does occur in 1.3rc2, but not
> 1.3b2. My confusion comes from the
Oh, great : )
--~--~-~--~~~---~--~~
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 email to
jquery-dev+unsu
Nope, not a typo. That + character allows .eq() to used with a
stringified number.
http://dev.jquery.com/ticket/3102
--
Ariel Flesler
http://flesler.blogspot.com
On Jan 15, 5:15 am, "David Zhou" wrote:
> Somewhat related, there's a small but harmless typo at
>
> http://dev.jquery.com/browser/t
Hmmm... the code is exactly as written in the test? Because
$('div:has("p+p')')
has 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
> probably
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
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 should I file a bug?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery
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 the debugger, or let
the script continue."
With the code:
$('div:has("p+p')')
And the HTML:
1
This worked fine with jQuery 1.2.6.
Test case: http://jsbin.com/atiha/edi
jQuery UI 1.6rc4 is only compatible with jQuery 1.2.6. 1.6rc5 will be
released today and be compatible with jQuery 1.3.
- Richard
On Thu, Jan 15, 2009 at 8:10 AM, lrbabe wrote:
>
> I'm not very certain about the origin of this problem, but it appears
> that when using the last release candidate
I'm not very certain about the origin of this problem, but it appears
that when using the last release candidate of jQuery-UI with the last
official release of jQuery, triggerHandler causes some problem.
Try to create a simple slider with a callback on "slide". Tell me if
the callback is triggered
Isn't that parent()?
Jörn
On Thu, Jan 15, 2009 at 11:30 AM, Just wrote:
>
> Thanks leeoniya !
>
> But ":eq(0)" can't work in my case.
> Work as ":first" and so return an only one element, so can't get each
> parent of each matched element :/.
>
> I'll look for the closest method.
>
> But think
Thanks leeoniya !
But ":eq(0)" can't work in my case.
Work as ":first" and so return an only one element, so can't get each
parent of each matched element :/.
I'll look for the closest method.
But think it should be very interesting to get a "first-ancestor" as
we have a "first-child".
On 14 j
57 matches
Mail list logo
