Maybe having a method detach would bring some clarity?
The removed child node still exists in memory, but is no longer part
of the DOM.
var orphan = this.removeChild(this.firstChild)
Above orphan is indeed not a part of the document. Why is this a
problem?
Why would I go back to the document,
Actually maybe new method is not needed. Instead maybe new argument to
remove() will
bring an end (and clarity) to the removal saga ?
var orphanage = document.createElement(div);
$(div.foo).remove( orphanage ) ;
If orphanage is provided, removed elements (aka orphans) will be
added to it.
If
@John I would like to ask the same thing DBJDBJ did. Why would you
want to find the index of an element that no longer exists? This just
seems unintuitive. You shouldn't be able to find the index of
something not in the document. The two sets of elements did refer to
the same thing, but no
Devon, some people like to remove elements and have the option of
adding some or all of them back into the DOM at a later time.
DBJDBJ, this is just FYI since you already retracted your suggestion
to add a .detach() method, but jQuery 1.4a already has a .detach()
method. It removes elements
Hi John
Perfect, thanks for the info and updating the docs
I've actually decided to change these particular scripts so they don't
branch on the submit value but other stuff.
Keep up the great work!!
Our intranet users hugely appreciate both jQuery and jQueryUI !!
Cheers, B
On Dec 14, 9:45 pm,
Ah, yes .. of course there is detach() already in 1.4. I remember it
now from a roadmap ...
And a new remove( selector, keepData ).
But. I am thinking on a more conceptual level. Not just on the API
level. jQuery is in essence a visitor/handler/mediator between a
persistent storage (dom tree) and
http://www.infoworld.com/d/windows/are-you-secret-ie-abuser-140
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
Karl,
it is not only href that has problems, seems all attributes having
an URI string as value have to be read in the way you described.
Some of them are: action, cite, codebase, data, href, longdesc,
lowsrc, src, usemap.
In IE6/7 elements have a predefined number of attributes (minimum 80,
On Dec 14, 12:31 am, John Resig jere...@gmail.com wrote:
For example, documenting that disabled/selected/etc. are expected to
return boolean values. Documenting the expected value returned from
zIndex. Documenting what happens with relative URL resolution across
browsers.
THEN we can go back
On Dec 15, 10:24 am, Diego Perini diego.per...@gmail.com wrote:
it is not only href that has problems, seems all attributes having
an URI string as value have to be read in the way you described.
Some of them are: action, cite, codebase, data, href, longdesc,
lowsrc, src, usemap.
The root
1) I cannot find the rationale for this. Or even where this bug is
discussed. Can anyone point me to it? I am curious.
// Safari mis-reports the default selected property of a hidden
option
// Accessing the parent's selectedIndex property fixes it
if ( name == selected
I think this is a great approach, and I hope it goes somewhere. How
exactly can I help with it?
Categorizing the types would be a great start. Types that should
just work, Types that should return booleans, types that we
obviously don't care about (attributes of isindex, for example), and
That article is junk.
They're ONLY tracking a small 20k group of people who have signed up for
their system, not the millions of relevant people.
They're also tracking servers which aren't being used by people.
They spout numbers like 80% (IE 2h a day) and 40% (IE 6h a day) saying
those are
Well, as a developer of applications for the web, I can definitely say that I
run IE 100% of the day. I also run FF, Opera and Safari 100% of the day.
Ps I hate IE.
-- Sent from my Palm Prē
DBJDBJ wrote:
http://www.infoworld.com/d/windows/are-you-secret-ie-abuser-140
--
You received this
On Dec 15, 11:21 am, John Resig jere...@gmail.com wrote:
Hmm, I don't remember the bug off-hand but here's the reproduction:
Failing:http://ejohn.org/files/bugs/selected/
Passing:http://ejohn.org/files/bugs/selected/fixed.html
Ah, I see. The description in the source is misleading.
Note that
On Dec 15, 11:32 am, John Resig jere...@gmail.com wrote:
I think this is a great approach, and I hope it goes somewhere. How
exactly can I help with it?
Categorizing the types would be a great start. Types that should
just work, Types that should return booleans, types that we
obviously
Karl, yes but this is about empty not remove, which means that the
parent of the removed elements is returned not the children
themselves. For example:
$(div.foo).empty() //returns div.foo not the children of div.foo
The element that we call empty on is not removed from the document so
I will take a look at this. I may come to different conclusions than
you, but I will propose something. Having a dump of all the attributes
and documenting what to expect from each would be fantastic.
Excellent, appreciate your help!
Doing a Google Code Search yields lots of interesting edge
I've been reading this thread right along and I apologize for being the late
one to the party, and I wasn't going to bother, because its not at the core
of the discussion, but I'm still perplexed.
Why would you want to use:
.attr('onclick', function() { /../ });
When exists:
.click(function()
Devon -
Let me explain this in a different way: You're creating a duplicate
copy of the element, one which isn't tied to anything.
Another way to illustrate it:
var divs = $(div);
// .length == 10
divs.eq(0).children().length
// 3
var empty = $(div).empty();
// .length == 10
John, that last resource you posted is great, kangax is the man.
Rick
On Tue, Dec 15, 2009 at 4:40 PM, John Resig jere...@gmail.com wrote:
I will take a look at this. I may come to different conclusions than
you, but I will propose something. Having a dump of all the attributes
and
21 matches
Mail list logo
