Asp Forum - references to DOM parts

ram

12/30/2015 6:21:00 PM

I have an HTML document that starts with

<!DOCTYPE HTML><html xmlns="http://www.w3.org/1999/x... lang="de" xml:lang="de">
<head><meta charset="UTF-8">

. Now, I define names for parts of the DOM via the JavaScript
console:

h = this.document.firstElementChild
hh = h.firstElementChild
m = hh.firstElementChild

. I perform the following evaluations in the Firefox Console
(one line is input, the next is output, then this repeats):

m.outerHTML
"<meta charset="UTF-8">"

m.outerHTML = '<meta charset="ISO-8859-1">'
"<meta charset="ISO-8859-1">"

m.outerHTML
"<meta charset="UTF-8">"

hh.firstElementChild.outerHTML
"<meta charset="ISO-8859-1">"

this.document.firstElementChild.firstElementChild.firstElementChild.outerHTML
"<meta charset="ISO-8859-1">"

One can see above that the assigment to »m.outerHTML«
has the intended effect when one looks at the result via »hh«,
but when one is looking via »m«, one still sees the old value.

The last evaluation shows that the DOM was really modified.
Why do I see the new value via »hh«, but not via »m«?

46 Answers

Aleksandro

12/30/2015 6:35:00 PM

On 30/12/15 15:20, Stefan Ram wrote:
> The last evaluation shows that the DOM was really modified.
> Why do I see the new value via »hh«, but not via »m«?

Because you got references to the actual DOM elements when asked for
them. The member access is not re-evaluated after that.

ram

12/30/2015 7:36:00 PM

Aleksandro <aleksandro@gmx.com> writes:
>On 30/12/15 15:20, Stefan Ram wrote:
>>The last evaluation shows that the DOM was really modified.
>>Why do I see the new value via »hh«, but not via »m«?
>Because you got references to the actual DOM elements when asked for
>them. The member access is not re-evaluated after that.

Thay's correct, but it is a very general, broad wording. In fact,
in the meantime, I learned that this seems to be related to
outerHTML in particular. An assignment to it seems to /overwrite/
the element reference /in the parent/ of the element with a
reference to a new element, and the previous reference will be
removed from the parent and therewith from the DOM, but it might
still be stored in variables such as »m«.

JJ

12/31/2015 4:48:00 AM

On 30 Dec 2015 18:20:39 GMT, Stefan Ram wrote:
> I have an HTML document that starts with
>
> <!DOCTYPE HTML><html xmlns="http://www.w3.org/1999/x... lang="de" xml:lang="de">
> <head><meta charset="UTF-8">
>
> . Now, I define names for parts of the DOM via the JavaScript
> console:
>
> h = this.document.firstElementChild
> hh = h.firstElementChild
> m = hh.firstElementChild
>
> . I perform the following evaluations in the Firefox Console
> (one line is input, the next is output, then this repeats):
>
> m.outerHTML
> "<meta charset="UTF-8">"
>
> m.outerHTML = '<meta charset="ISO-8859-1">'
> "<meta charset="ISO-8859-1">"
>
> m.outerHTML
> "<meta charset="UTF-8">"
>
> hh.firstElementChild.outerHTML
> "<meta charset="ISO-8859-1">"
>
> this.document.firstElementChild.firstElementChild.firstElementChild.outerHTML
> "<meta charset="ISO-8859-1">"
>
> One can see above that the assigment to »m.outerHTML«
> has the intended effect when one looks at the result via »hh«,
> but when one is looking via »m«, one still sees the old value.
>
> The last evaluation shows that the DOM was really modified.
> Why do I see the new value via »hh«, but not via »m«?

Assignment to outerHTML property creates a new HTML object and if succeeded,
it replaces the old one. So the m value is not changed. It's still reference
to the old HTML object which is now an orphan element.

Evertjan.

12/31/2015 10:11:00 AM

JJ <jj4public@vfemail.net> wrote on 31 Dec 2015 in comp.lang.javascript:

> On 30 Dec 2015 18:20:39 GMT, Stefan Ram wrote:
>> I have an HTML document that starts with
>>
>> <!DOCTYPE HTML><html xmlns="http://www.w3.org/1999/x... lang="de"
>> xml:lang="de"> <head><meta charset="UTF-8">
>>
>> . Now, I define names for parts of the DOM via the JavaScript
>> console:
>>
>> h = this.document.firstElementChild
>> hh = h.firstElementChild
>> m = hh.firstElementChild
>>
>> . I perform the following evaluations in the Firefox Console
>> (one line is input, the next is output, then this repeats):
>>
>> m.outerHTML
>> "<meta charset="UTF-8">"
>>
>> m.outerHTML = '<meta charset="ISO-8859-1">'
>> "<meta charset="ISO-8859-1">"
>>
>> m.outerHTML
>> "<meta charset="UTF-8">"
>>
>> hh.firstElementChild.outerHTML
>> "<meta charset="ISO-8859-1">"
>>
>> this.document.firstElementChild.firstElementChild.firstElementChild.oute
>> rHTML "<meta charset="ISO-8859-1">"
>>
>> One can see above that the assigment to »m.outerHTML«
>> has the intended effect when one looks at the result via »hh«,
>> but when one is looking via »m«, one still sees the old value.
>>
>> The last evaluation shows that the DOM was really modified.
>> Why do I see the new value via »hh«, but not via »m«?
>
> Assignment to outerHTML property creates a new HTML object and if
> succeeded, it replaces the old one. So the m value is not changed. It's
> still reference to the old HTML object which is now an orphan element.

Would the "var m" assignment not prevent it
from being a real orphan [in the sense of gabage-collectable]?

.... as it can be reassigned anywhere in the DOM-tree later?

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

JJ

12/31/2015 2:15:00 PM

On Thu, 31 Dec 2015 11:11:01 +0100, Evertjan. wrote:
>
> Would the "var m" assignment not prevent it
> from being a real orphan [in the sense of gabage-collectable]?
>
> ... as it can be reassigned anywhere in the DOM-tree later?

Yes to both.

It's like assigning a variable to the return value of removeChild() then
re-insert the node into the document later using appendChild() or
insertBefore(). Without saving a reference to the removed node, the node
would be a garbage.

Aleksandro

12/31/2015 4:35:00 PM

On 31/12/15 11:15, JJ wrote:
> On Thu, 31 Dec 2015 11:11:01 +0100, Evertjan. wrote:
>>
>> Would the "var m" assignment not prevent it
>> from being a real orphan [in the sense of gabage-collectable]?
>>
>> ... as it can be reassigned anywhere in the DOM-tree later?
>
> Yes to both.
>
> It's like assigning a variable to the return value of removeChild() then
> re-insert the node into the document later using appendChild() or
> insertBefore(). Without saving a reference to the removed node, the node
> would be a garbage.

I think would apply the same rules as to any Javascript object.

Evertjan.

12/31/2015 6:20:00 PM

Aleksandro <aleksandro@gmx.com> wrote on 31 Dec 2015 in
comp.lang.javascript:

> On 31/12/15 11:15, JJ wrote:
>> On Thu, 31 Dec 2015 11:11:01 +0100, Evertjan. wrote:
>>>
>>> Would the "var m" assignment not prevent it
>>> from being a real orphan [in the sense of gabage-collectable]?
>>>
>>> ... as it can be reassigned anywhere in the DOM-tree later?
>>
>> Yes to both.
>>
>> It's like assigning a variable to the return value of removeChild() then
>> re-insert the node into the document later using appendChild() or
>> insertBefore(). Without saving a reference to the removed node, the node
>> would be a garbage.
>
> I think would apply the same rules as to any Javascript object.

Is the Javascript-object garbage-collection the same as the DOM-tree-element
one?

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

Aleksandro

12/31/2015 6:42:00 PM

On 31/12/15 15:19, Evertjan. wrote:
> Aleksandro <aleksandro@gmx.com> wrote on 31 Dec 2015 in
> comp.lang.javascript:
>
>> On 31/12/15 11:15, JJ wrote:
>>> On Thu, 31 Dec 2015 11:11:01 +0100, Evertjan. wrote:
>>>>
>>>> Would the "var m" assignment not prevent it
>>>> from being a real orphan [in the sense of gabage-collectable]?
>>>>
>>>> ... as it can be reassigned anywhere in the DOM-tree later?
>>>
>>> Yes to both.
>>>
>>> It's like assigning a variable to the return value of removeChild() then
>>> re-insert the node into the document later using appendChild() or
>>> insertBefore(). Without saving a reference to the removed node, the node
>>> would be a garbage.
>>
>> I think would apply the same rules as to any Javascript object.
>
> Is the Javascript-object garbage-collection the same as the DOM-tree-element
> one?

DOM elements are normal Javascript objects, or should be. Someone
confirm please.

JR

12/31/2015 11:24:00 PM

On 12/31/2015 04:41 PM, Aleksandro wrote:
> On 31/12/15 15:19, Evertjan. wrote:
>> Aleksandro <aleksandro@gmx.com> wrote on 31 Dec 2015 in
>> comp.lang.javascript:
>>
>>> On 31/12/15 11:15, JJ wrote:
>>>> On Thu, 31 Dec 2015 11:11:01 +0100, Evertjan. wrote:
>>>>>
>>>>> Would the "var m" assignment not prevent it
>>>>> from being a real orphan [in the sense of gabage-collectable]?
>>>>>
>>>>> ... as it can be reassigned anywhere in the DOM-tree later?
>>>>
>>>> Yes to both.
>>>>
>>>> It's like assigning a variable to the return value of removeChild() then
>>>> re-insert the node into the document later using appendChild() or
>>>> insertBefore(). Without saving a reference to the removed node, the node
>>>> would be a garbage.
>>>
>>> I think would apply the same rules as to any Javascript object.
>>
>> Is the Javascript-object garbage-collection the same as the DOM-tree-element
>> one?
>
> DOM elements are normal Javascript objects, or should be. Someone
> confirm please.
>

DOM objects are host objects (called exotic objects in ES6), not
ECMAScript's ordinary or standard built-in objects. The W3C defined the
DOM as a set of objects and interfaces for accessing and manipulating
document objects in a language-independent manner. The DOM presents
documents as a hierarchy of Node objects that also implement other, more
specialized interfaces.

If I write the following lines in my Chrome 47 (Linux Mint) console, I
will find the "HTMLParagraphElement" object.

var el = document.createElement('p');
console.log(el.constructor.prototype); // logs HTMLParagraphElement

And if I follow the prototype chain, I will find other object names that
correspond to DOM Level 4 interfaces:

HTMLParagraphElement
HTMLElement
Element
Node
EventTarget
Object

BTW, Happy New Year!

--
Joao Rodrigues

JJ

12/31/2015 11:54:00 PM

On Thu, 31 Dec 2015 15:41:30 -0300, Aleksandro wrote:
>
> DOM elements are normal Javascript objects, or should be. Someone
> confirm please.

They're normal.
A parentless but owned DOM node has a referene to a document, but the
document doesn't have a reference to it.

That node increase document's reference count by one since it needs the
document, but the document doesn't need the node so it doesn't increase the
node's reference count.

Thus, the node keeps the document alive (longer) and not become a garbage,
and the document doesn't keep the node alive and makes it a garbage.

The Document.adoptNode() should have been Node.setOwner().
The Document.importNode() should have been Node.exportToDocument().

comp.lang.javascript

references to DOM parts

ram

Aleksandro

ram

JJ

Evertjan.

JJ

Aleksandro

Evertjan.

Aleksandro

JR

JJ

x Login to ForumsZone