This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The remove() method from Interface Element [ http://www.w3.org/TR/dom/#dom-childnode-remove ] is overwritten with The remove() method from Interface HTMLSelectElement [ http://www.w3.org/TR/REC-DOM-Level-1/level-one-html.html#ID-33404570 ] for the select nodes. Today, I have to use something like this: window.HTMLSelectElement && function(HTMLSelectElementPrototype) { var removeOption = HTMLSelectElementPrototype.remove; HTMLSelectElementPrototype.remove = function() { if (arguments[0] >= 0) removeOption.call(this, arguments[0]); else this.parentNode && this.parentNode.removeChild(this); }; }(window.HTMLSelectElement.prototype); It would be better to change HTMLSelectElement Interface so that without arguments it used remove method like Element Interface.
Hrm, <http://www.whatwg.org/html/#the-select-element> has void remove(long index); so I guess we could make it work with our void remove(); but I'm not sure if WebIDL supports that... Cameron?
One option would be for HTMLSelectElement to define overloads with and without and index and explicitly say that the no-argument overload does the same thing as the canonical Element.prototype.remove. That's how an ES implementation would have to implement it, and I think specifying it that way is simplest. It also happens to be simple to implement, at least in Gecko. ;)
Ian, care to make that change in HTML?
I agree with Boris; that's the simplest solution. (I think overloading operations with those from an inherited interface could be confusing for the reader.)
Hi guys! I was wondering what is the difference between selectNode.remove(optionIndex) and selectNode[optionIndex].remove()? Do we need 2 different methods for doing extactly the same thing? Maybe this situation occurred because the method "remove" from HTMLSelectElement interface was so replaceable and too few people really enjoyed them? Maybe it is time for him to retire?
HTMLSelectElement.remove(i) removes the i'th option element from the this element; ChildNode.remove() removes the this object from its parent, if any.
HTMLSelectElement.remove(i) - removes the i'th option HTMLSelectElement[i].remove() - removes the i'th option it is 100% replaceable, am I right?
Sure. We can't remove select.remove(i), though, because pages use that.
Is a pity, it would be a little easier.
Having remove() remove the element from its parent and remove(i) remove a child from the element is very confusing. Can't we rename ChildNode.remove()?
WebKit already implemented ChildNode.remove() by Erik Arvidsson, and Google Chrome 24(stable) has it now. http://wkrev.com/129400 http://wkb.ug/73885 But I guess that web developers aren't so using ChildNode.remove()...
Do you have a better name?
unparent() removeFromParent() detach()
I'm kicking this over to DOM, because remove() on HTMLSelectElement is ancient and having both do basically opposite things is going to be very confusing.
It does not seem that confusing to me that on one element there is an overloaded version that removes a child via an index which is largely a legacy API anyway.
How is a method that does two diametrically opposite things not confusing??
So I don't think we're going to change. Hmm.
Firefox 23 ships this.
Checked in as WHATWG revision r8192. Check-in comment: remove() is also defined on an ancestor interface, so overload it here on <select>. http://html5.org/tools/web-apps-tracker?from=8191&to=8192