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

Groups > comp.lang.javascript > #30150

Re: onload and onclick

Show all headers | View raw

Thomas 'PointedEars' Lahn wrote:
> Stefan Weiss wrote:
>> | On the other hand, parsing of HTML files happens asynchronously and
>> | incrementally, meaning that the parser can pause at any point to let
>> | scripts run.
>>
>> The parser, having parsed and created the "start" element, pauses to let
>> the script add a "click" listener to it. There is _no_ potential for a
>> race condition as with "load", which is what that part of the spec warns
>> about.
> 
> You are misinterpreting this.  What it really says is that inline script 
> code can be executed at any time, whether the element in question had been 
> parsed by the HTML parser and added as an object to the document tree before 
> or not.  If it has not been added yet, or is incompletely processed, the 
> inline script code assuming otherwise will fail in some way.
>
>> Adding click listeners before the DOMContentLoaded stage has always
>> worked just fine.
> 
> Lucky you.  As I said, it is not guaranteed.  Never has been.

It does not matter if there is or isn't an actual written guarantee in
the specification, because when a script is executed before the
"DOMContentLoaded" stage, the previously parsed (complete) elements
*are* available in the DOM. This is the way browsers have been working
for a very, very long time - making it a de facto standard. Thousands of
scripts rely on this behavior.

What did not always work reliably was modifying the tree by inserting,
deleting, or moving nodes around before the containing element finished
parsing. Remember the infamous "Operation aborted" error in IE? That's
what happened when the tree structure was modified before the browser
was ready - and even back then it was fine to add event listeners during
parsing.

As a matter of fact, I wouldn't be at all surprised if this behavior
actually is specified in HTML5. It's hard to keep up with 1150 pages of
"living standard", and I've never had a reason to read the immense
section about parsing, but there are some passages that highly suggest
that the DOM is intended to be available during parsing. Here are some
rather extreme examples:

  A<script>
  var text = document.createTextNode('B');
  document.body.appendChild(text);
  </script>C

  A<script>
  var text = document.getElementsByTagName('script')[0].firstChild;
  text.data = 'B';
  document.body.appendChild(text);
  </script>C

https://html.spec.whatwg.org/multipage/syntax.html#creating-and-inserting-nodes

Given time, I could probably find the section that directly specifies
all this, but I'm already wasting too much time here.

>>>> - Strict mode makes no difference in this particular function, so the
>>>>   "use strict" statement could be left out.
>>>
>>> Questionable advice.
>>
>> This was _not_ advice. Learn to read.
> 
> BTDT.  “Could be left out” without even a comment as to why this would be a 
> bad idea is equivalent to a recommendation.  Especially to a beginner.

I completely disagree. I was listing some variations that could make the
code more compact, which is what the OP asked for. I followed by saying
that I would do the opposite of what I just described. If you really
read that as advice, I have to repeat: learn to read.

>>>> - Explicitly referring to the `window` object is optional;
>>>
>>> Cite evidence.
>>
>> No, do your own homework.
> 
> IOW, you do not substantiate your claim, so we can safely assume it is 
> nonsense based on wishful thinking and insufficient testing.

A - statement
B - give evidence
A - no
B - statement is therefore false

If this passes as logic for you, it explains a lot. Nevermind that we're
talking about exactly this topic in the next paragraphs...

Let me just reiterate that I am in no way advocating setting the
property implicitly. I was merely pointing out that it is possible and
legal.

>> If you're actually going to assume that `onload` is somehow in danger of
>> being something other than intended, then `window` is affected in exactly
>> the same way.
> 
> No, because “window.onload” is always a property access, a standalone 
> “onload” is not always one.

I don't see what difference the type of access makes. Both `window` and
`onload` can be set to anything. Note that in current browsers this is
no longer possible in the top scope, since neither are writable, but you
can still do this:

  (function () {
    var window = {};
    window.onload = ...
  })();

 (function () {
    var onload = {};
    onload = ...
  })();

And they both break just the same. So the "Really Bad Idea" is actually:
don't shadow the names of built-in objects or properties and then rely
on them. This is neither new nor surprising.

>>> What if it is strict mode code?
>>
>> 1) Nothing. Not a problem.
> 
> Incorrect.  Assignment to a non-existing property of a distinct object is 
> relatively harmless in strict mode.  Reference, and particularly assignment, 
> to an identifier that fails to be resolved at the top end of the scope chain 
> throws a ReferenceError exception in strict mode instead.

Does not apply, because `onload` can _always_ be resolved at the top of
the scope chain. It is a specified predefined property of the Window
object. Now demonstrate how assignment to bare `onload` can trigger a
ReferenceError in a document (strict mode or not).

> Also, since one 
> cannot know the scope chain in an HTML document with certainty, with an 
> identifier there is always the possibility that there is an object in the 
> scope chain before that has a corresponding property.  For example, it could 
> be the object referred to by the “form” or “document” property.

That's the same non-argument as above. Stuff can be shadowed, big whoop.

>> 2) We know the code, we're not in global strict mode.
> 
> We know the *current* code of a *beginner*.

The OP has asked a specific question and given us all the context we
need. He even included a function-level "use strict" statement. The
assumption that we're somehow in global strict mode anyway is ludicrous.

>>> Yes, the event listener should be added.  But [addEventListener()] does 
>>> not work in IE < 9, and IE 9 in Compatibility Mode. [...]
...
>> Anyway, this is easily fixed by using an additional `false` argument.
> 
> Nonsense.  The method itself is not available in the named circumstances.

Right, I noticed that as soon as I hit reply. I thought about posting an
addendum, but I thought I'd let you have a win.


- stefan

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

onload and onclick emf <emfril@gmail.com> - 2016-03-28 08:07 -0400
  Re: onload and onclick Stefan Weiss <krewecherl@gmail.com> - 2016-03-28 22:47 +0200
    Re: onload and onclick Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-28 23:23 +0200
      Re: onload and onclick Frank Kozuschnik <franko@nurfuerspam.de> - 2016-03-29 00:20 +0200
        Re: onload and onclick Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-29 00:43 +0200
      Re: onload and onclick Stefan Weiss <krewecherl@gmail.com> - 2016-03-29 00:57 +0200
        Re: onload and onclick Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-29 02:04 +0200
          Re: onload and onclick Stefan Weiss <krewecherl@gmail.com> - 2016-03-29 04:47 +0200
            Re: onload and onclick Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-31 20:06 +0200
              Re: onload and onclick Aleksandro <aleksandro@gmx.com> - 2016-03-31 15:37 -0300
              Re: onload and onclick Stefan Weiss <krewecherl@gmail.com> - 2016-04-02 01:43 +0200
    Re: onload and onclick Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-29 00:33 +0200
    Re: onload and onclick Stefan Weiss <krewecherl@gmail.com> - 2016-03-29 05:03 +0200
    Re: onload and onclick emf <emfril@gmail.com> - 2016-03-29 01:45 -0400
  Re: onload and onclick Aleksandro <aleksandro@gmx.com> - 2016-03-28 18:33 -0300

csiph-web