No, appendChild is a DOM property that adds a pointer from one DOM node, a parent, to another DOM node, a child. While a DOM node is represented in JavaScript as an object literal pointers, however, are just a means to describe some data link. In my opinion Firefox is the only browser that probably gets this correct.
First of all the prototype object does not even have a method called "appendChild", so it is inheriting from the prototype of the global object named "object". To add to this, the appendChild method is not defined in the core of JavaScript but is supplied for access as part of the DOM collection. If there is no DOM then appendChild is likely absent without any change to how prototype operates. Secondly, the "===" operator matches against both type and value. In the case of your example both sides probably have the same type, but each probably evaluate to a falsy value. If that falsy value is static in both type and instantiation then there is no problem like evaluating a false condition against numeric 0 with type coercion. However, if a value is not implied, such as undefined or NaN then the evaluation is false on each side, but each side is lacking a value instance and so the comparison would return false as well. This means that most browsers are likely supplying a value of null to each side, which can be compared. Firefox probably evaluates each side to undefined because you have a pointer that is not supplied enough information to properly instantiate, meaning a pointer that is not pointing to anything. If you compare null to null the result is true, but if you compare undefined to undefined the result is false. For additional exploration run this from the server side and see what happens. I am guessing that even the V8 powered Node.js would return false, but I could be wrong. Thanks, Austin Cheney, CISSP -----Original Message----- From: jsmentors@googlegroups.com [mailto:jsmentors@googlegroups.com] On Behalf Of Kumar Sent: Monday, September 26, 2011 12:39 PM To: The JSMentors JavaScript Discussion Group Subject: [JSMentors] Re: URL Blocker On Firefox, the following condition returns false while it returns true on Chrome/Safari and even for Opera Element.prototype.appendChild === HTMLElement.prototype.appendChild Don't you think this is sort of bad on part of Firefox? Shouldn't HTMLElement, HTMLBodyElement, HTMLHeadElement... and so on, all of them, should essentially be inheriting prototypes from the base "Element" class? Given this fact, how to override appendChild api for all DOM elements? On Aug 2, 7:17 pm, "Fyodorov "bga" Alexander" <bga.em...@gmail.com> wrote: > On Aug 1, 3:43 pm, UI Architect <info > > > > > > > > > > %webuiarchitect....@gtempaccount.com> wrote: > > I need to build an URL blocker script that would block requests to a > > given set of URLs. > > > With whatever knowledge I have so far, DOM doesn't have any 'change' > > event itself; so practically this seems impossible. So I have changed > > the problem statement to - "Remove any element from the DOM as soon as > > possible after it makes a request to a blocked URL". > > > 1) SCRIPT - since changing the src attribute of a SCRIPT element > > doesn't make any difference to the DOM, only the new SCRIPT elements > > need to be tracked against blocked URLs. > > > 2) IFRAME & IMG - both of these types need to be tracked for existing > > as well as new elements being added in the DOM against the blocked > > URLs. > > > The approach I'm thinking of is to start an interval, collect existing > > target elements, check the src attributes and remove those elements > > from DOM. > > > And may be, innerHTML and appendChild methods can be overwritten to do > > a pre-check for blocked URLs. > > > Can you please suggest better approaches? I need to have a 'best > > possible' solution - need not be perfect and 100% full-proof. > > First - wrap XHR#open, XDR#open, WebSocket and EventSource. > Second - if browser supports [gs]etters and DOM prototypes - wrap > setter HTML[Image|Frame|Script|Embed]Element#src, > HTMLObjectEvent#data, also Node#setAttribute method . Else if browser > supports onpropertychange event - (poll DOM tree changes or use DOM > mutation events), add onpropertychange and wrap setAttribute > individually for each element w/ #src/data arttribute but its less > effective and may be big overhead. -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
