Since it doesn't yield the same result as wrapInner(html), i just
filed a ticket on wrapInner(fn);
http://dev.jquery.com/ticket/5799
On Jan 13, 9:42 pm, ajpiano wrote:
> I've also been taking a look at wrapInner(function), which is
> essentially .contents().wrapAll(function
have a half-written ticket on this too, but
wasn't so sure it actually needs "correcting."
On Jan 13, 9:04 pm, ajpiano wrote:
> No problem.
>
> http://dev.jquery.com/ticket/5798
>
> On Jan 13, 8:21 pm, Dave Methvin wrote:
>
>
>
> > > This seems like bug
No problem.
http://dev.jquery.com/ticket/5798
On Jan 13, 8:21 pm, Dave Methvin wrote:
> > This seems like bug territory. Wish I'd found this earlier.
>
> Can you file a ticket on this? It does seem wrong.
--
You received this message because you are subscribed to the Google Groups
"jQuery Dev
The context of the callback function is not right when you use
replaceWith(function);
$("h3").replaceWith(function(i) {
console.log(this);
return ""+$(this).html()+""; //broke because the next
element of my h3 was coming up as a textnode.
The fact that $("*").bind() is WAY worse than $(document).bind()
really ought to be shouted from the rooftops.
On Jan 13, 11:46 am, John Resig wrote:
> Well, before we had a very "non-silent" failure - and that was causing
> his, and others, applications to break. I'm a firm believer that good
>
http://dev.jquery.com/ticket/5779
For those who don't feel like searching anymore...
On Jan 13, 9:48 am, helianthus wrote:
> John Arrowwood was kind enough to do it for
> me:http://groups.google.com/group/jquery-dev/browse_thread/thread/dba343...
>
> But I thought this could be fixed before the
It is definitely odd that which is standardised in mouse button
events, but button is not.
On Jan 11, 12:01 pm, helianthus wrote:
> http://github.com/jquery/jquery/blob/master/src/event.js#L401
>
> I did not know that there has been normalization for event.which until
> looking up the new API bro
This strikes me as almost a little bit too much sugar...to streamline
this type of binding/filtering, I tend to think it might just be
easier to perhaps use the jQuery.ui.keyCode object and move that into
core, perhaps? I think the idea is to save people needing to do the
keycode lookups, not nece
+1
On Dec 29, 4:39 pm, Peter Higgins wrote:
> ajpiano wrote:
> > That said, and while I do love (and frequently recommend) $.hitch, I
> > prefer an approach more like Prototype or Underscore's that doesn't
> > involve passing so many strings.
>
> > --ada
I love the idea of extending scope manipulation to any function,
rather than only event handlers. Callbacks to ajax requests often
need a better scope than the XHR, and while I look forward to 1.4's
functionality for event handlers, it would really be a shame to
continue to force people to use non
; >>>> then yeah, consider .contains() gone (and a jQuery.contains will be
> >>>> provided for those that need a lightweight method).
>
> >>>> --John
>
> >>> But if .has() returns a boolean, then we have the same problem
> &
PS. Enjoy your kneecaps for the rest of the holiday season...
On Dec 23, 9:17 pm, ajpiano wrote:
> > Naturally #jquery is still the best place for general Q&A.
>
> Or for being kind and charitable and giving support to those who need
> it ;)
>
> --adam
>
> On Dec
> Naturally #jquery is still the best place for general Q&A.
Or for being kind and charitable and giving support to those who need
it ;)
--adam
On Dec 21, 11:18 pm, John Resig wrote:
> #jquery-dev isn't very active - amusingly the most active place for
> jQuery dev discussion is #jquery-ot (for
s(). Hmm. If .has() returns a boolean
> then yeah, consider .contains() gone (and a jQuery.contains will be
> provided for those that need a lightweight method).
>
> --John
>
>
>
> On Wed, Dec 16, 2009 at 11:04 PM, ajpiano wrote:
> > It seems like a matter of course t
It seems like a matter of course that means of filtering that are
exposed as both pseudoselectors and methods on the jQuery prototype
return the same set of elements, or at least that they generally apply
the same principle in filtering. Examples include eq, not, first,
last, and has. While the :
Dec 13, 8:24 pm, John Resig wrote:
>
>
>
> > The most frequent case I've seen is $().ready() (which still works and
> > I plan on continuing to make work, at least for the time being). I
> > haven't really seen other cases being used in the wild - do you have
>
A recent commit -
http://github.com/jquery/jquery/commit/04524287d3e0112deae570ff9247c734833431bb
- changed the behaviour of $() from $(document) to $([]).
This is a change that I can truly jibe with, and I think the behaviour
makes sense. No one likes having to do $([]) to create an empty jQuery
Not sure if this merits a ticket because it ventures off into the
world of "things that people don't actually do," but I figured it was
at least worth a mention.
in jQuery 1.3.2
var foo = $("foo").parent() // returns a DIV
wrapped with jQuery, and accordingly
foo.find("span").length === 1;
in jQu
The "Write Less, Do More" tagline comes to mind. By standardising
common, low-level tasks, jQuery allows the ambitious JavaScript
developer to focus on functionality rather than reinventing the wheel
in project after project.
On Aug 30, 11:58 pm, Erik Reppen wrote:
> and _$ and _jQuery
>
> :)
This discussion is more appropriate to the jQuery general discussion
list, http://groups.google.com/group/jquery-en
On Aug 18, 5:59 am, lrbabe wrote:
> A link to your website could be helpful
>
> On Aug 18, 7:39 am, Samer Ziadeh wrote:
>
> > could be positioning or floats of the element, if so
should be doing this instead?
>
> var content = $('#content')[0];
> $('.posts', content);
>
>
>
> On Mon, Aug 17, 2009 at 14:30, ajpiano wrote:
>
> > Thanks for clarifying this. The very same section in Brandon's post
> > had me
Thanks for clarifying this. The very same section in Brandon's post
had me confused, and also had me writing $(".these",$those[0])
since.
On Aug 16, 4:46 am, James Padolsey
wrote:
> Thanks for your reply John. :)
>
> On Aug 14, 1:24 pm, John Resig wrote:
>
> > > That can't be true, right? It d
It has been repeatedly stated that jQuery has NO plans to drop support
for IE7, and that pretty much everything in jQuery that is there for
IE7 also is there for IE6, meaning that support for the two pretty
much comes in tandem. IE6 is a bitch to develop for, we all know
that, but I don't think w
This list is not for the discussion of the use of jQuery, but rather
for its development. Use the http://groups.google.com/group/jquery-en
list for discussion of this type.
Most likely the two libraries are conflicting. Look into
jQuery.noConflict().
On Jun 10, 1:20 pm, youradds wrote:
> Ok,
caching of jQuery objects, it's not
> enough to use 'any' selector once if you depend on highly-modified DOMs you
> would always have to repeat the search.
>
>
>
> On Wed, Jun 3, 2009 at 2:25 PM, ajpiano wrote:
>
> > In all honesty, this was a functionality
In all honesty, this was a functionality I was hot for maybe a year
ago, but probably wouldn't need much today. I cache collections all
the time, and I recommend it highly to new users. Users of jQuery
should be WAY more aware of the simple fact that $() is a constructor,
but many are not. If t
Over the years there has been considerable interest in providing
conditional chaining functionality to jQuery, though nothing has ever
been cemented.
http://groups.google.com/group/jquery-en/browse_thread/thread/43a69fa41f6e7089/6cebfee318992fe6
http://groups.google.com/group/jquery-dev/browse_th
This question is better suited to the jQuery UI mailing list.
http://groups.google.com/group/jquery-ui
On Jun 1, 7:20 pm, sAvEoURpLAnET wrote:
> Hi,
>
> I had this code in a single file, and I want to refresh each Dialog
> content every time I open it.
>
>
> maxlength="10" class="my_class"
This is definitely useful and necessary. I'd put my two cents for it
being called either "scope" or "context," which, though "taken,"
describe the actual purpose of the additional argument. "pointer"
might also be an appropriate name.
--adam
On May 5, 1:22 pm, Nathan Bubna wrote:
> Why not st
I tend to think an alternate build being available from the website
would tend to be confusing to the average consumer, especially given
the fact that Object.prototype "insurance" is a goal for an upcoming
release (so I've heard...) It won't be very long before Google grabs
this thread and expose
It seems like you are attaching information directly to arbitrary
jQuery objects, rather than using the .data() method, which from a
cursory read seems like it would be appropriate.
--adam
On Mar 7, 10:02 am, Dave Methvin wrote:
> > var button = makeNewButton().addClass('TestButton').appendTo(p
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
I don't know how much harder the point that @ is gone can be driven
home. It was deprecated in 1.2.6. A major problem is bad/outdated
tutorials that are still telling people the wrong way.
On Feb 12, 10:35 am, David Zhou wrote:
> Actually, nevermind. I forgot there was a changes section:
>
>
This may seem close-minded, but I tend to think the need to delete a
node from the DOM and hold onto that exact node the way it was when it
left the DOM in the event that exact node needs to be re-inserted is
kind of a specific implementation that shouldn't be handled natively
by .remove(). I've
maybe a few jquery event shortuts to specific keycodes/ranges of
keycodes, which would provide a meaningful semantic layer, as opposed
to further entrenching the spread of ranges of valid numeric keycodes
into our jquery events
$(...).bind("keydown[enter] keydown[numeric]",fn)
or maybe even simp
It would be useful to be able to use the .index() method to find the
index of the current element in a given set, rather than the current
implementation (searching the current set for a given element), which
forces the developer to do gyrations in order to find out a simple
piece of info.
For in
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
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
Seems interesting and if it works more power to ya but I think it's a
bit excessive to have jQuery automatically start applying classes to
all body tags unconditionally (in order to do something that the
developer might not even need). Pretty much the opposite of
unobtrusive.
On Dec 8, 10:40 am
This list is for discussion of the development of the jQuery library
itself, for general questions relating to its use please use the
general list:
http://groups.google.com/group/jquery-en
Furthermore, events should be bound to elements, rather than through
inline event handlers or "href='javasc
Similarly nifty would be the ability to select based on metadata, an
implementation of which can be found at
http://erikandcolleen.com/erik/projects/jquery/metaselector/
and I would tend to think that selecting based on metadata would share
a lot of the logic of selecting based on .data() store.
FWIW, I agree that it should have the same args as the other
callbacks. Just as all the jQuery ui callbacks get e,ui, it stands to
reason the callbacks should be standardised...
--adam
On Sep 11, 10:13 am, "Brian Relph" <[EMAIL PROTECTED]> wrote:
> I think I agree with you that it does not matt
42 matches
Mail list logo
