Path: csiph.com!.POSTED.194-73-239-109.cust.centrio.cz!not-for-mail From: Cezary Tomczyk Newsgroups: comp.lang.javascript Subject: Re: Inserting stuff received with AJAX into the DOM Date: Sat, 26 Aug 2017 09:25:44 +0200 Organization: csiph.com Internet News Service Message-ID: References: <7e54d58e-0ce6-4bb5-9f07-f65b69a94a64@googlegroups.com> <5846bd55-f0bd-4088-a596-aba50eef32a5@googlegroups.com> <11843581.uLZWGnKmhe@PointedEars.de> <7340100.T7Z3S40VBb@PointedEars.de> <19530051.EfDdHjke4D@PointedEars.de> <6718455.EvYhyI6sBW@PointedEars.de> <3126118.iIbC2pHGDl@PointedEars.de> <8133365.CDJkKcVGEf@PointedEars.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sat, 26 Aug 2017 07:25:43 +0000 (UTC) Injection-Info: csiph.com; posting-host="194-73-239-109.cust.centrio.cz:109.239.73.194"; logging-data="26410"; mail-complaints-to="admin@kev009.com" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 In-Reply-To: <8133365.CDJkKcVGEf@PointedEars.de> Content-Language: en-GB Xref: csiph.com comp.lang.javascript:33875 On 21/08/2017 22:16, Thomas 'PointedEars' Lahn wrote: > Cezary Tomczyk wrote: > >> On 21/08/2017 17:47, Thomas 'PointedEars' Lahn wrote: >>> Cezary Tomczyk wrote: >>>> On 21/08/2017 16:44, Thomas 'PointedEars' Lahn wrote: >>>>> Cezary Tomczyk wrote: >>>>>> I am sure that: >>>>>> >>>>>> const par = document.createElement( 'p' ); >>>>>> >>>>>> will always create HTML element. I can't see any real scenario where >>>>>> createElement method will return "something else than a reference to >>>>>> an object that has a method named “appendChild”" in that particular >>>>>> scenario. >>>>> >>>>> Why? >>>> >>>> https://developer.mozilla.org/en-US/docs/Web/API/Document/createElement >>>> […] >>> Certainly you can come up with something better than hearsay. >> >> Possibly there is a better explanation than just hearsay. > > Possibly. Can you come up with it? No. I was expecting you'll do that. >>>> In that particular case: >>>> >>>> const par = document.createElement( 'p' ); >>>> >>>> this will return an HTML p element. >>> >>> It may. >> >> Well, recently you wrote: >> >> "As a rule of thumb, if the object in question always had the method and >> it always worked, I do not feature-test it." >> >> Isn't now that case? > > This is not about not feature-testing the createElement() method. It is > about testing its return value before using that. Got it, but still I claim that in that particular case I would not test it. >> I might be wrong, but if there are cases that may strongly require "if" >> here then I'd like to know. > > You are trying to shift the burden of proof again. You have claimed that > this method can never return something unsuitable. So how do *you* support > that claim *other* than with hearsay from MDN (I called it “hearsay” because > it is a wiki and there is no other reference attached to your claim)? > You have claimed that this method can never return something unsuitable. Let me clarify it: it may return something unexpected, but I've never tested return value from createElement method before I use it because 1) it was always working as expected and 2) I haven't got any scenario where I could say it's required. >>>> I would say and even, if it'll occur then calling "appendChild" later >>>> will throw a DOM exception which I think it's good because it helps to >>>> catch the error on an early stage. >>> An exception, but not a “DOM exception” will be thrown, if the object >>> does not have the method. Or execution will simply stop with an error. >>> Who knows. createElement() is a host object’s method. >> >> Right, an exception. > > So, what if no exception is being thrown by a method, would you not want to > make sure as best as you can that the return value of a method is actually a > reference to an object, before you attempt to access its properties? Generally yes, but as for the returns from createElement method I do not do that. >> createElement() is a host object’s method, but it was always available > > This is simply not true. Maybe you are too young to know it: > > Before the W3C DOM, which became a W3C Recommendation in 1998 CE (and was > quickly adopted through Mozilla 1.0 in 2000), there have been element > objects that did not have that method because it was introduced with the > aforementioned API. > > In what was called “Dynamic HTML” (DHTML) at the time, in Netscape Navigator > (and later, Communicator) 4.x, there were layer objects for `LAYER` (and > IIRC, `DIV`) elements whose content you could replace by calling their > write() method; and in Internet Explorer and other MSHTML-based user agents > there were element objects which had only the “innerHTML” and “outerHTML” > properties, and several other methods (like insertAdjacentHTML() recently > mentioned by Martin) for this instead. > >> and unless it's not modified it has been always working quite good. > > Based on what *data*? Own experience. I'd rather strongly urge to give me a scenarios where createElement method returns something different than created HTML element. I'd like to understand why do I need to test a return value of createElement method if it's actually a reference to an object, before I attempt to access to it's properties. -- Cezary Tomczyk http://www.ctomczyk.pl/