On Tue, Sep 27, 2011 at 6:13 AM, Cheney, Austin < [email protected]> wrote:
> 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. > "appendChild" is DOM method defined on the Element interface in the IDL definitions. The W3C DOM 2 specification doesn't say exactly how inheritance must be implemented in its ECMAScript bindings. There is no "right" way to do it. There isn't even a requirement that there is an Element or HTMLElement constructor available, nor that DOM objects must have a prototype chain, it only speaks about the required properties of the DOM objects. There have been (still is?) implementations where DOM objects were thin wrappers around the C++ document implementation, with no inheritance, no Javascript constructor functions or prototype chains, etc. I'm not sure whether HTML5 changes this, but at first glance it doesn't seem so. It merely defines the interfaces that DOM objects must satisfy, but doesn't require that these interfaces are reflected as constructors, or that DOM objects must have any inherited properties or any prototype chain at all. I'm not absolutely sure though, haven't read the HTML5 doc thoroughly. > 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. > Yes, "appendChild" is a DOM method, which is why we are talking about the Element and HTMLElement constructors. I'm not sure which "prototype object" you are talking about. > > 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. Unlikely, both are functions, and therefore objects. Using === is just checking for object identity. > 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. > I'm not sure this makes sense, sorry. > 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. No, comparing undefined to undefined is also true. Maybe you are thinking of NaN? > 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. > That would make little sense, since we are talking about DOM properties. /L > > -----Original Message----- > From: [email protected] [mailto:[email protected]] 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" > <[email protected]> wrote: > > On Aug 1, 3:43 pm, UI Architect <info > > > > > > > > > > > > > > > > > > > > %[email protected]> 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/[email protected]/ > > To search via a non-Google archive, visit here: > http://www.mail-archive.com/[email protected]/ > > To unsubscribe from this group, send email to > [email protected] > > -- > To view archived discussions from the original JSMentors Mailman list: > http://www.mail-archive.com/[email protected]/ > > To search via a non-Google archive, visit here: > http://www.mail-archive.com/[email protected]/ > > To unsubscribe from this group, send email to > [email protected] > -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
