Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.javascript > #34743 > unrolled thread

Re: What's wrong with using a global id?

Started byJJ <jj4public@vfemail.net>
First post2018-02-25 22:20 +0700
Last post2018-03-02 17:06 +0100
Articles 6 — 4 participants

Back to article view | Back to comp.lang.javascript

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: What's wrong with using a global id? JJ <jj4public@vfemail.net> - 2018-02-25 22:20 +0700
    Re: What's wrong with using a global id? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-02-25 17:37 +0100
      Re: What's wrong with using a global id? Julio Di Egidio <julio@diegidio.name> - 2018-02-25 09:16 -0800
        Re: What's wrong with using a global id? Julio Di Egidio <julio@diegidio.name> - 2018-02-25 10:19 -0800
      Re: What's wrong with using a global id? Jon Ribbens <jon+usenet@unequivocal.eu> - 2018-02-26 15:18 +0000
        Re: What's wrong with using a global id? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-03-02 17:06 +0100

#34743 — Re: What's wrong with using a global id?

FromJJ <jj4public@vfemail.net>
Date2018-02-25 22:20 +0700
SubjectRe: What's wrong with using a global id?
Message-ID<1ec3czl2mmgku$.y2l7ncexmwul$.dlg@40tude.net>
On 25 Feb 2018 04:19:12 GMT, Stefan Ram wrote:
>   (I also showed them that given
> 
> <p id="null">
> 
> this.null
>   did not refer to the element while

`this.null` will never refer to the global `null` object, even if `this` is
the global object. The `null` object resides in the global context, instead
of the global object as a property.

> document.getElementById( "null" )
> 
>   did.

It doesn't. What browser did you use to check that? Even MSIE v6 doesn't.

> There also might be several other ids that do not
>   appear as a global property.)

As long as there's a variable exist in the global context before the HTML
element is added into the HTML document, the HTML element ID will never
replace the existing variable.

[toc] | [next] | [standalone]


#34744

FromThomas 'PointedEars' Lahn <PointedEars@web.de>
Date2018-02-25 17:37 +0100
Message-ID<1593727.VLH7GnMWUR@PointedEars.de>
In reply to#34743
JJ wrote:

> On 25 Feb 2018 04:19:12 GMT, Stefan Ram wrote:
>>   (I also showed them that given
>> 
>> <p id="null">
>> 
>> this.null
>>   did not refer to the element while
             ^^^^^^^^^^^^^^^^^^^^ 
> `this.null` will never refer to the global `null` object,

Straw man.

> even if `this` is the global object. The `null` object resides in the
> global context, instead of the global object as a property.

There is no such thing as a “global null object”.  “null” (without quotation 
marks) is the sole value of the *primitive* Null type.
 
>> document.getElementById( "null" )
>> 
>>   did.
     ^^^ 
> It doesn't. What browser did you use to check that? Even MSIE v6 doesn't.

Yes, it does.  You have confused his argument with your 
misunderstanding/straw man of it.
 
>> There also might be several other ids that do not
>>   appear as a global property.)
> 
> As long as there's a variable exist in the global context before the HTML
> element is added into the HTML document, the HTML element ID will never
> replace the existing variable.

The order does not matter at all.

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

[toc] | [prev] | [next] | [standalone]


#34745

FromJulio Di Egidio <julio@diegidio.name>
Date2018-02-25 09:16 -0800
Message-ID<51622cff-5033-4dd9-8c8b-90463a338e0f@googlegroups.com>
In reply to#34744
On Sunday, 25 February 2018 17:37:33 UTC+1, Thomas 'PointedEars' Lahn  wrote:
> JJ wrote:
> > On 25 Feb 2018 04:19:12 GMT, Stefan Ram wrote:
> >>   (I also showed them that given
> >> 
> >> <p id="null">
> >> 
> >> this.null
> >>   did not refer to the element while
>              ^^^^^^^^^^^^^^^^^^^^ 

I only see sparse pieces of this conversation.
Isn't "null" there just a string, i.e. the id of that element?
Then the this.null, in a context where the *this* does refer
to the element object, shouldn't just work?

Julio

[toc] | [prev] | [next] | [standalone]


#34746

FromJulio Di Egidio <julio@diegidio.name>
Date2018-02-25 10:19 -0800
Message-ID<328b8031-6b4f-4425-8d41-754cb3af3146@googlegroups.com>
In reply to#34745
On Sunday, 25 February 2018 18:16:35 UTC+1, Julio Di Egidio  wrote:
> On Sunday, 25 February 2018 17:37:33 UTC+1, Thomas 'PointedEars' Lahn  wrote:
> > JJ wrote:
> > > On 25 Feb 2018 04:19:12 GMT, Stefan Ram wrote:
> > >>   (I also showed them that given
> > >> 
> > >> <p id="null">
> > >> 
> > >> this.null
> > >>   did not refer to the element while
> >              ^^^^^^^^^^^^^^^^^^^^ 
> 
> I only see sparse pieces of this conversation.
> Isn't "null" there just a string, i.e. the id of that element?
> Then the this.null, in a context where the *this* does refer
> to the element object, shouldn't just work?

No, sorry, of course "this.null" makes very little sense anyway...

Julio

[toc] | [prev] | [next] | [standalone]


#34752

FromJon Ribbens <jon+usenet@unequivocal.eu>
Date2018-02-26 15:18 +0000
Message-ID<slrnp9899v.31p.jon+usenet@sable.unequivocal.eu>
In reply to#34744
On 2018-02-25, Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
> JJ wrote:
>> As long as there's a variable exist in the global context before the HTML
>> element is added into the HTML document, the HTML element ID will never
>> replace the existing variable.
>
> The order does not matter at all.

What do you mean by that? What JJ said there appears to be true,
and of course gives the reason why relying on window[id] is a bad
idea - because you don't know what different browsers or future
browser versions already have in the window object and therefore
you don't know whether window[id] will be your HTML element or
something else entirely.

  > var n = document.createElement("span")
  > n.setAttribute("id", "randomstring")
  > document.getElementsByTagName("body")[0].appendChild(n)
  > console.log(window.randomstring)

    <span id="randomstring"></span>

  > var n2 = document.createElement("span")
  > n2.setAttribute("id", "otherrandomstring")
  > window.otherrandomstring = 1
  > document.getElementsByTagName("body")[0].appendChild(n2)
  > <span id="otherrandomstring"></span>
  > console.log(window.otherrandomstring)

    1

[toc] | [prev] | [next] | [standalone]


#34756

FromThomas 'PointedEars' Lahn <PointedEars@web.de>
Date2018-03-02 17:06 +0100
Message-ID<11612235.kPQ6UWO93G@PointedEars.de>
In reply to#34752
Jon Ribbens wrote:

> On 2018-02-25, Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
>> JJ wrote:
>>> As long as there's a variable exist in the global context before the
>>> HTML element is added into the HTML document, the HTML element ID will
>>> never replace the existing variable.
>> The order does not matter at all.
> 
> What do you mean by that? What JJ said there appears to be true,

But it is not.  Their statement is gibberish; I understand it to mean:

“As long as a variable […] exist[s] in the global context before the HTML 
element is added [to] the HTML document, the [ID of that element] will never 
[cause the value of an existing variable to be replaced].”

And *it does not matter* whether a (global) variable was declared in a 
“script” element before or after the other element in question in source 
code order: the (global) variable *always* takes precedence.

Tested in an HTML5 environment in Chromium 57 (navigator.userAgent === 
"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) 
Chrome/57.0.2987.98 Safari/537.36") and Firefox 52 (navigator.userAgent === 
"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0"), but 
AFAIK this has always been so in all scriptable Web browsers that had a 
considerable market share at the time.

Without creating a new HTML document, you can test it in the developer 
console of an existing HTML document in more recent versions of Web browsers 
as follows:

/* ---------------------------------------------------------------------- */
(function () {
  "use strict";

  function El (type, properties)
  {
    var el = document.createElement(type);

    /* NOTE: Does not handle nested properties */
    return Object.assign(el, properties);
  }

  function append (el)
  {
    return document.body.appendChild(el);
  }

  function execute (code)
  {
    return append(El("script", {
      type: "text/javascript",
      textContent: code
    }));
  }

  execute(`
    function tryAndCatch (f)
    {
      try
      {
        f();
      }
      catch (e)
      {
        console.error(e);
      }
    }

    tryAndCatch(function () {
      console.log("Before #foo (should throw instead): " + foo);
    });
  `);

  execute(`
    tryAndCatch(function () {
      console.assert(foo === void 0,
        "“foo” should be “undefined” before variable assignment");
    });

    var foo = 42;

    console.assert(foo === 42,
      "“foo” should be 42 after variable assignment");
  `);

  append(El("div", {id: "foo"}));
  append(El("div", {id: "bar"}));

  execute(`
    tryAndCatch(function () {
      console.assert(foo === 42, "“foo” should still be 42 after #foo");
    });

    tryAndCatch(function () {
      console.assert(bar === void 0,
        "“bar” should be “undefined” before variable assignment");
    });

    var bar = 11;

    console.assert(bar === 11,
      "“bar” should be 11 after variable assignment");
  `);
}());
/* ---------------------------------------------------------------------- */

> and of course gives the reason why relying on window[id] is a bad
> idea - because you don't know what different browsers or future
> browser versions already have in the window object and therefore
> you don't know whether window[id] will be your HTML element or
> something else entirely.

“window[id]” is _not_ a variable.  /Ex falso sequitur quodlibet/; even 
correct conclusions.
 
>   > var n = document.createElement("span")
>   > n.setAttribute("id", "randomstring")
>   > document.getElementsByTagName("body")[0].appendChild(n)
>   > console.log(window.randomstring)
> 
>     <span id="randomstring"></span>
> 
>   > var n2 = document.createElement("span")
>   > n2.setAttribute("id", "otherrandomstring")
>   > window.otherrandomstring = 1

That is not a variable either.

>   > document.getElementsByTagName("body")[0].appendChild(n2)
>   > <span id="otherrandomstring"></span>
>   > console.log(window.otherrandomstring)
> 
>     1

Your test case addresses a different situation than “JJ” described, it runs 
in a different execution context, and if it works, it produces potentially 
invalid markup.  Also, you have neglected to specify your test environment. 
So this is neither relevant nor convincing.

I suggest that you familiarize yourself with the basics of the used markup 
and programming languages first; then with the features of the HTML(5) DOM − 
including, but not limited to, shorthand properties like “id” and 
“document.body”.

Good starting points are

<https://developer.mozilla.org/en-US/docs/HTML>
<https://developer.mozilla.org/en-US/docs/JavaScript>
<https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model>

and of course the FAQ (see below).

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

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.javascript


csiph-web