Inserting stuff received with AJAX into the DOM

[bit-n...@hotmail.com]

Assume I've run an AJAX call, and got back a response, which I put into the variable "rt":

rt = request.responseText;


I would now like to append this text to the DOM tree using appendChild, but it keeps giving this error:

"TypeError: Argument 1 of Node.appendChild is not an object."


I guess "rt" is not an object - it's just text. What is one supposed to do in this case?


Btw, I would NOT like the text to show up immediately when I do the appendChild - anything special that needs to be done??


Thanks.

[bit-n...@hotmail.com]

Just to add - I would like to add "rt" into the DOM tree as a <DIV> *with a particular id* - how do I do that??

[Thomas 'PointedEars' Lahn]

Stefan Ram wrote:

> bit-n...@hotmail.com writes:
>>Just to add - I would like to add "rt" into the DOM tree as a
>><DIV> *with a particular id* - how do I do that??
>

> I'm not an expert in DOM scripting, here is an untested attempt:

s/DOM//

> { const text = document.createTextNode( rt );
> const par = document.createElement( 'p' ); par.appendChild( text );
> const div = document.createElement( 'div' ); div.appendChild( par );
> div.setAttribute( 'id', 'particularid' );
> whereyouwanttoappendit.appendChild( div ); }

Using the “const” keyword makes this code unnecessily incompatible. It is
also questionable whether “const” satisfies the semantics of the code as the
referred values are highly mutable.

The first thing that one wants to do is to test each return values before
one uses it:

if (par && text) par.appendChild(text);

Even better, in a function is the “gauntlet” or “early return” approach:

if (!(par && text)) return …;

Note that unfortunately not all DOM implementations have returned a
reference to the appended node from .appendChild() in the past, so while
method chaining may be appealing, it is not wise.

Then

div.setAttribute( 'id', 'particularid' );

can and should be

div.id = "particularid";

as it avoids one less backwards-compatible method call.

Other than that, the approach is sound: It is more efficient to construct a
subtree in memory and append it, than to append the separate nodes to the
document directly. The goal here is to minimize the number of reflows.

--
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[Thomas 'PointedEars' Lahn]

Stefan Ram wrote:

> bit-n...@hotmail.com writes:

>>rt = request.responseText;

>>"TypeError: Argument 1 of Node.appendChild is not an object."
>>I guess "rt" is not an object - it's just text.
>

> You can use »document.createTextNode« to create a text entry
> from a string.

(You are missing the point of the problem here, but ISTM that you have
gotten it later.)

It is possible, but unlikely, that an XHR response would not contain markup.
Therefore, one should either parse the returned markup into a document whose
content can be imported, and appended to a parent element node of a document
(one wants to create – with document.createDocumentFragment() – use, and
append a document fragment in case of several nodes to be appended) –

var doc = (new DOMParser()).parseFromString(…, "text/html");
….appendChild(document.importNode(doc.…, true));

– or assign it to the “innerHTML” property of that parent element node.

[Cezary Tomczyk]

On 20/08/2017 12:16, Thomas 'PointedEars' Lahn wrote:
> Stefan Ram wrote:
>
>> bit-n...@hotmail.com writes:
>>> Just to add - I would like to add "rt" into the DOM tree as a
>>> <DIV> *with a particular id* - how do I do that??
>>
>> I'm not an expert in DOM scripting, here is an untested attempt:
>
> s/DOM//
>
>> { const text = document.createTextNode( rt );
>> const par = document.createElement( 'p' ); par.appendChild( text );
>> const div = document.createElement( 'div' ); div.appendChild( par );
>> div.setAttribute( 'id', 'particularid' );
>> whereyouwanttoappendit.appendChild( div ); }
>
> Using the “const” keyword makes this code unnecessily incompatible. It is
> also questionable whether “const” satisfies the semantics of the code as the
> referred values are highly mutable.
>
> The first thing that one wants to do is to test each return values before
> one uses it:
>
> if (par && text) par.appendChild(text);
>
> Even better, in a function is the “gauntlet” or “early return” approach:
>
> if (!(par && text)) return …;

My approach would be a bit different. I would rather not do that as "if"
statement here tends to hides the potential error. Better, in my
opinion, is to use directly:

par.appendChild(text);

"par" is always defined, but text doesn't have to be or can be passed as
a non-string type. In that case executing par.appendChild(text); will
throw DOM exception and the error can be spotted easily.

[...]

--
Cezary Tomczyk
http://www.ctomczyk.pl/

[bit-n...@hotmail.com]

...OK, for some reason Google Groups is not showing Stefan Ram's posts, so I'm reading them quoted in other people's! :( Could someone quote the entire messages please?

What does " document.createElement( 'p' ); " return, exactly? An object?
And why the "const"?

[Evertjan.]

bit-n...@hotmail.com wrote on 20 Aug 2017 in comp.lang.javascript:

> ...OK, for some reason Google Groups is not showing Stefan Ram's posts,
> so I'm reading them quoted in other people's! :( Could someone quote the
> entire messages please?

Use a real Newsgroup-reader, this NG is not a Google-group.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Thomas 'PointedEars' Lahn]

Cezary Tomczyk wrote:

> On 20/08/2017 12:16, Thomas 'PointedEars' Lahn wrote:
>> Stefan Ram wrote:
>>> { const text = document.createTextNode( rt );
>>> const par = document.createElement( 'p' ); par.appendChild( text );
>>> const div = document.createElement( 'div' ); div.appendChild( par );
>>> div.setAttribute( 'id', 'particularid' );
>>> whereyouwanttoappendit.appendChild( div ); }

>> […]

>> The first thing that one wants to do is to test each return values before
>> one uses it:
>>
>> if (par && text) par.appendChild(text);
>>
>> Even better, in a function is the “gauntlet” or “early return” approach:
>>
>> if (!(par && text)) return …;
>
> My approach would be a bit different. I would rather not do that as "if"
> statement here tends to hides the potential error. Better, in my
> opinion, is to use directly:
>
> par.appendChild(text);
>

> "par" is always defined, […]

How did you get that idea?

[bit-n...@hotmail.com]

OK, I got it working to some extent, but now, after I set the id to "myid", it actually SHOWS UP on screen when I do the appendChild!!! i.e. this line:

<div id="myid">text</div>


is getting printed!!


How do I stop this??!!

[Cezary Tomczyk]

On 20/08/2017 19:18, Thomas 'PointedEars' Lahn wrote:
> Cezary Tomczyk wrote:
>
>> On 20/08/2017 12:16, Thomas 'PointedEars' Lahn wrote:
>>> Stefan Ram wrote:
>>>> { const text = document.createTextNode( rt );
>>>> const par = document.createElement( 'p' ); par.appendChild( text );
>>>> const div = document.createElement( 'div' ); div.appendChild( par );
>>>> div.setAttribute( 'id', 'particularid' );
>>>> whereyouwanttoappendit.appendChild( div ); }
>>> […]
>>> The first thing that one wants to do is to test each return values before
>>> one uses it:
>>>
>>> if (par && text) par.appendChild(text);
>>>
>>> Even better, in a function is the “gauntlet” or “early return” approach:
>>>
>>> if (!(par && text)) return …;
>>
>> My approach would be a bit different. I would rather not do that as "if"
>> statement here tends to hides the potential error. Better, in my
>> opinion, is to use directly:
>>
>> par.appendChild(text);
>>
>> "par" is always defined, […]
>
> How did you get that idea?

const par = document.createElement( 'p' );

[Thomas 'PointedEars' Lahn]

And you are sure that the method that is called on the right-hand side of
that assignment cannot possibly return something else than a reference to
an object that has a method named “appendChild”?

[Evertjan.]

bit-n...@hotmail.com wrote on 20 Aug 2017 in comp.lang.javascript:

Pull out the mains plug of your printer!

[Cezary Tomczyk]

On 20/08/2017 22:39, Thomas 'PointedEars' Lahn wrote:
> Cezary Tomczyk wrote:
>
>> On 20/08/2017 19:18, Thomas 'PointedEars' Lahn wrote:
>>> Cezary Tomczyk wrote:
>>>> "par" is always defined, […]
>>> How did you get that idea?
>>
>> const par = document.createElement( 'p' );
>
> And you are sure that the method that is called on the right-hand side of
> that assignment cannot possibly return something else than a reference to
> an object that has a method named “appendChild”?

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.

Correct me, if I am wrong.

[Andrew Poulos]

On 21/08/2017 9:29 AM, Evertjan. wrote:
> bit-n...@hotmail.com wrote on 20 Aug 2017 in comp.lang.javascript:
>
>> OK, I got it working to some extent, but now, after I set the id to
>> "myid", it actually SHOWS UP on screen when I do the appendChild!!! i.e.
>> this line:
>>
>> <div id="myid">text</div>
>>
>>
>> is getting printed!!
>>
>>
>> How do I stop this??!!
>
> Pull out the mains plug of your printer!

What if it's battery operated?

---

Add a media query to the CSS eg.

@media print {
#myid {
display:none;
}
}

Andrew Poulos

[Evertjan.]

Andrew Poulos <ap_...@hotmail.com> wrote on 21 Aug 2017 in
comp.lang.javascript:

> On 21/08/2017 9:29 AM, Evertjan. wrote:
>> bit-n...@hotmail.com wrote on 20 Aug 2017 in comp.lang.javascript:
>>
>>> OK, I got it working to some extent, but now, after I set the id to
>>> "myid", it actually SHOWS UP on screen when I do the appendChild!!! i.e.
>>> this line:
>>>
>>> <div id="myid">text</div>
>>>
>>>
>>> is getting printed!!
>>>
>>>
>>> How do I stop this??!!
>>
>> Pull out the mains plug of your printer!
>
> What if it's battery operated?

Pull out the battery.

> ---
>
> Add a media query to the CSS eg.
>
> @media print {
> #myid {
> display:none;
> }
>}

That will just print an empty page,
at least more empty than before.

[Thomas 'PointedEars' Lahn]

Cezary Tomczyk wrote:

> On 20/08/2017 22:39, Thomas 'PointedEars' Lahn wrote:
>> Cezary Tomczyk wrote:
>>> On 20/08/2017 19:18, Thomas 'PointedEars' Lahn wrote:
>>>> Cezary Tomczyk wrote:
>>>>> "par" is always defined, […]
>>>> How did you get that idea?
>>> const par = document.createElement( 'p' );
>> And you are sure that the method that is called on the right-hand side of
>> that assignment cannot possibly return something else than a reference to
>> an object that has a method named “appendChild”?
>
> 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?

> Correct me, if I am wrong.

Nice try :)

[Thomas 'PointedEars' Lahn]

Andrew Poulos wrote:

> On 21/08/2017 9:29 AM, Evertjan. wrote:
>> bit-n...@hotmail.com wrote on 20 Aug 2017 in comp.lang.javascript:
>>> OK, I got it working to some extent, but now, after I set the id to
>>> "myid", it actually SHOWS UP on screen when I do the appendChild!!! i.e.
>>> this line:
>>>
>>> <div id="myid">text</div>
>>>
>>>
>>> is getting printed!!
>>>
>>>
>>> How do I stop this??!!
>>
>> Pull out the mains plug of your printer!
>
> What if it's battery operated?

Are there such devices?

> ---
>
> Add a media query to the CSS eg.
>
> @media print {
> #myid {
> display:none;
> }
> }

I do not think that “being printed” was meant as “being printed out on
paper”. As has already been recognized, markup being displayed is the
result of setting as the contents of a *text* node instead of an
*element* node.

[Cezary Tomczyk]

On 21/08/2017 16:44, Thomas 'PointedEars' Lahn wrote:
> Cezary Tomczyk wrote:
>
>> On 20/08/2017 22:39, Thomas 'PointedEars' Lahn wrote:
>>> Cezary Tomczyk wrote:
>>>> On 20/08/2017 19:18, Thomas 'PointedEars' Lahn wrote:
>>>>> Cezary Tomczyk wrote:
>>>>>> "par" is always defined, […]
>>>>> How did you get that idea?
>>>> const par = document.createElement( 'p' );
>>> And you are sure that the method that is called on the right-hand side of
>>> that assignment cannot possibly return something else than a reference to
>>> an object that has a method named “appendChild”?
>>
>> 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

"In an HTML document, the Document.createElement() method creates the
HTML element specified by tagName, or an HTMLUnknownElement if tagName
isn't recognized. In a XUL document, it creates the specified XUL
element. In other documents, it creates an element with a null namespace
URI."

In that particular case:

const par = document.createElement( 'p' );

this will return an HTML p element.

As for "something else than a reference to an object that has a method
named “appendChild”" may occur, of course, but this is a very rare case
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.

I just don't see a benefit of using "if" statement here instead of simple:

par.appendChild(text);

>> Correct me, if I am wrong.
>
> Nice try :)

:-)

[Thomas 'PointedEars' Lahn]

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.

> In that particular case:
>
> const par = document.createElement( 'p' );
>
> this will return an HTML p element.

It may.

> As for "something else than a reference to an object that has a method
> named “appendChild”" may occur, of course, but this is a very rare case

When in doubt, be careful.

> 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.

> I just don't see a benefit of using "if" statement here instead of simple:
>
> par.appendChild(text);

Defensive programming.

[Cezary Tomczyk]

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.

>> 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?

I might be wrong, but if there are cases that may strongly require "if"
here then I'd like to know.

>> As for "something else than a reference to an object that has a method
>> named “appendChild”" may occur, of course, but this is a very rare case
>
> When in doubt, be careful.

:-)

>> 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.

createElement() is a host object’s method, but it was always available
and unless it's not modified it has been always working quite good.

[Thomas 'PointedEars' Lahn]

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?

>>> 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.

> 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)?

>>> 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?

> 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*?

[Cezary Tomczyk]

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.

[Thomas 'PointedEars' Lahn]

Cezary Tomczyk wrote:

> 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.

That is precisely your fallacy here. He who makes a claim carries the
burden of proof to support it; not others carry the burden of proof to
refute the same claim or prove the opposite claim.

>> 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.

It does not matter what you claim. It matters on what kind of reasoning you
are basing your (design) decisions.

>>> 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.

That is precisely the problem. Your decisions are apparently based only on
wishful thinking.

>> 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.

Not being based on sound reasoning, your decision-making process is not
logical.

>>> and unless it's not modified it has been always working quite good.
>> Based on what *data*?
>
> Own experience.

Do you realize that one’s experience is limited?

> 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.

You are trying to shift the burden of proof again. I am not playing that
game.

Also, please trim your quotes from now on.

.
.
.