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

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

onload and onclick

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

Contents

  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

#30128 — onload and onclick

The eye exercises at:

http://emf.neocities.org/ix/ix.html

are working fine (after I was finally able to upload all the files I 
wanted) My question revers to he function that fires them:

window.onload = function () {
     "use strict";
     document.getElementById("start").onclick = function () {
         requestFullScreen();
         init();
     };
};

I arrived at this solution after deciding to remove any JS code from the 
HTML code. It works fine, however it looks a little too complicated for 
my personal taste. Is there a simpler way to write it?

emf

-- 
Spherical Triangle Calculator
http://emf.neocities.org/tr/spherical.html

[toc] | [next] | [standalone]

#30133

emf wrote:
> window.onload = function () {
>     "use strict";
>     document.getElementById("start").onclick = function () {
>         requestFullScreen();
>         init();
>     };
> };
> 
> I arrived at this solution after deciding to remove any JS code from the
> HTML code. It works fine, however it looks a little too complicated for
> my personal taste. Is there a simpler way to write it?

This is pretty typical code for what you're doing. There are a few
variations that could make it a little more concise, but nothing
dramatic. For example:

- If you include this script after the element with the ID "start", you
  don't have to wait for the "load" event before you assign a click
  handler to the element.
- Strict mode makes no difference in this particular function, so the
  "use strict" statement could be left out.
- Explicitly referring to the `window` object is optional; you could
  write `onload = function ()...` with the same effect.

Personally, I wouldn't use any of these. I would even go a step in the
opposite direction and use the more verbose `addEventListener()` method
instead of the DOM-0 style "onload" and "onclick" properties:

  window.addEventListener("load", function () {
      // etc
  });

This allows for more than one listener per target and event type, which
is particularly useful for the "load" event.

Most people use libraries to simplify common tasks like event handling
and element selection. With one such library, your code might look like
this:

  $(function () {
      $("#start").click(function () {
          requestFullScreen();
          init();
      });
  });

That's shorter (and also uses the "DOMready" event). Loading a huge
library for just a few lines of code would be counterproductive, but
typically the library gets used for the rest of the code, as well.


- stefan

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

#30136

Stefan Weiss wrote:

> emf wrote:
>> window.onload = function () {
>>     "use strict";
>>     document.getElementById("start").onclick = function () {
>>         requestFullScreen();
>>         init();
>>     };
>> };
>> 
>> I arrived at this solution after deciding to remove any JS code from the
>> HTML code. It works fine, however it looks a little too complicated for
>> my personal taste. Is there a simpler way to write it?
> 
> This is pretty typical code for what you're doing. There are a few
> variations that could make it a little more concise, but nothing
> dramatic. For example:
> 
> - If you include this script after the element with the ID "start", you
>   don't have to wait for the "load" event before you assign a click
>   handler to the element.

Not guaranteed:

<https://www.w3.org/TR/2014/REC-html5-20141028/introduction.html#common-pitfalls-to-avoid-when-using-the-scripting-apis>

> - Strict mode makes no difference in this particular function, so the
>   "use strict" statement could be left out.

Questionable advice.  If the function is later augmented with source code to 
which strict mode would be relevant, those checks would not be performed.  
And the OP is evidently not ECMAScript-savvy enough to know when strict mode 
would apply so chances are that they would not add the declaration later.

The standing recommendation, particularly to beginners, is to declare strict 
mode *locally* (which the OP has done, although it could be declared for a 
“module” of the module pattern as well), unless legacy code requires 
otherwise *and* cannot be easily rewritten to accomodate strict mode.
*A lot* of common beginner’s mistakes are detected this way.

> - Explicitly referring to the `window` object is optional;

Cite evidence.

> you could write `onload = function ()...` with the same effect.

A Really Bad Idea.  What if there happens to be a property of an object or a 
variable in the scope chain that is not the targeted object?  What if it is 
strict mode code?  This change makes the code less compatible and harder to 
reuse *at no advantage*.
 
> Personally, I wouldn't use any of these. I would even go a step in the
> opposite direction and use the more verbose `addEventListener()` method
> instead of the DOM-0 style "onload" and "onclick" properties:
> 
>   window.addEventListener("load", function () {
>       // etc
>   });
> 
> This allows for more than one listener per target and event type, which
> is particularly useful for the "load" event.

Yes, the event listener should be added.  But verbatim this does not work in 
IE < 9, and IE 9 in Compatibility Mode.  So if that is a problem a wrapper 
is required.  (Microsoft has terminated support for versions before IE *11* 
in January. [1]  We have removed IE 8 support last year [IIRC], and are 
going to stop actively supporting IE 9 sometime this year.)

[1] <https://www.microsoft.com/en-us/WindowsForBusiness/End-of-IE-support>
 
> Most people use libraries to simplify common tasks like event handling
> and element selection.

ACK.

> With one such library, your code might look like this:
> 
>   $(function () {
>       $("#start").click(function () {
>           requestFullScreen();
>           init();
>       });
>   });

Looks like jQuery-based code where .on("click", …) is recommended instead, 
for extensibility and consistency.
 
> That's shorter (and also uses the "DOMready" event). Loading a huge
> library for just a few lines of code would be counterproductive, but
> typically the library gets used for the rest of the code, as well.

Still, one should carefully assess what features of the library are actually 
used, and use a tailored version, and the library wrappers only when 
necessary.  Should the library wrappers not be necessary at all, then the 
reasonable decision is not to use the library.

<http://youmightnotneedjquery.com/>

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

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

#30142

Thomas 'PointedEars' Lahn:

> (Microsoft has terminated support for versions before IE *11* in
> January. [1]  We have removed IE 8 support last year [IIRC], and
> are going to stop actively supporting IE 9 sometime this year.)
>
> [1] <https://www.microsoft.com/en-us/WindowsForBusiness/End-of-IE-support>

For some Windows versions, older IE versions are still supported because 
no newer version is available. For each Windows version, Microsoft 
supports the most current version of Internet Explorer that is available 
for this Windows version.

For example, IE 9 is the most current version of Internet Explorer on 
Windows Vista SP2 and Windows Server 2008 SP2, and this means that IE 9 
is still supported on these Windows versions (as long as these Windows 
versions themselves are supported).

<https://support.microsoft.com/en-us/lifecycle#gp/Microsoft-Internet-Explorer>

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

#30144

Frank Kozuschnik wrote:

> Thomas 'PointedEars' Lahn:
>> [1]
>> [<https://www.microsoft.com/en-us/WindowsForBusiness/End-of-IE-support>
> 
> For some Windows versions, older IE versions are still supported because
> no newer version is available. For each Windows version, Microsoft
> supports the most current version of Internet Explorer that is available
> for this Windows version.
> […]
> <https://support.microsoft.com/en-us/lifecycle#gp/Microsoft-Internet-> Explorer>

Thank you, that clarification is very important.  (So we might have to 
continue supporting IE 9 until Extended Support ends for Windows Vista SP2: 
2017-04-11. Yuck^H^H^Hahoo! ;-))

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

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

#30146

Thomas 'PointedEars' Lahn wrote:
> Stefan Weiss wrote:
>> - If you include this script after the element with the ID "start", you
>>   don't have to wait for the "load" event before you assign a click
>>   handler to the element.
> 
> Not guaranteed:
> 
> <https://www.w3.org/TR/2014/REC-html5-20141028/introduction.html#common-pitfalls-to-avoid-when-using-the-scripting-apis>

That specific section you linked to actually supports what I 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.

Adding click listeners before the DOMContentLoaded stage has always
worked just fine.

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

> If the function is later augmented with source code to which strict
> mode would be relevant

Sure, and if my grandmother had wheels she'd be a wagon.

I said "this particular function". If you modify the code, the statement
no longer applies to it.

>> - Explicitly referring to the `window` object is optional;
> 
> Cite evidence.

No, do your own homework.

>> you could write `onload = function ()...` with the same effect.
> 
> A Really Bad Idea.  What if there happens to be a property of an object or a 
> variable in the scope chain that is not the targeted object?

We actually have the full code in this case and can easily see that
there is no such custom object or property. Creating one would be a
Really Bad Idea, indeed. 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.

> What if it is strict mode code?

1) Nothing. Not a problem.

2) We know the code, we're not in global strict mode.

> This change makes the code less compatible and harder to 
> reuse *at no advantage*.

Hence:

>> Personally, I wouldn't use any of these.

...
>>   window.addEventListener("load", function () {
>>       // etc
>>   });
>>
>> This allows for more than one listener per target and event type, which
>> is particularly useful for the "load" event.
> 
> Yes, the event listener should be added.  But verbatim this does not work in 
> IE < 9, and IE 9 in Compatibility Mode.  So if that is a problem a wrapper 
> is required.  (Microsoft has terminated support for versions before IE *11* 
> in January. [1]  We have removed IE 8 support last year [IIRC], and are 
> going to stop actively supporting IE 9 sometime this year.)

So, you no longer support IE8, but I should? Anyway, this is easily
fixed by using an additional `false` argument. Libraries generally take
care of that, too.


- stefan

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

#30148

Stefan Weiss wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Stefan Weiss wrote:
>>> - If you include this script after the element with the ID "start", you
>>>   don't have to wait for the "load" event before you assign a click
>>>   handler to the element.
>> 
>> Not guaranteed:
>> 
>> <https://www.w3.org/TR/2014/REC-html5-20141028/introduction.html#common-pitfalls-to-avoid-when-using-the-scripting-apis>
> 
> That specific section you linked to actually supports what I wrote:

On the contrary.
 
> | 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.  That is why 
there are those events (and even the jQuery zealots recommend to use them).
 
>>> - 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.

>>> - 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.
 
>>> you could write `onload = function ()...` with the same effect.
>> A Really Bad Idea.  What if there happens to be a property of an object
>> or a variable in the scope chain that is not the targeted object?
> 
> We actually have the full code in this case and can easily see that
> there is no such custom object or property.

See below.

> Creating one would be a Really Bad Idea, indeed.

Only if one followed your unwise "non-advice".

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

>> 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.  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.
 
> 2) We know the code, we're not in global strict mode.

We know the *current* code of a *beginner*.
 
>> This change makes the code less compatible and harder to
>> reuse *at no advantage*.
> 
> Hence:
> 
>>> Personally, I wouldn't use any of these.

Given the context, this can be interpreted in multiple ways, not all 
favorable to you.
 
>> Yes, the event listener should be added.  But [addEventListener()] does 
>> not work in IE < 9, and IE 9 in Compatibility Mode.  So if that is a
>> problem a wrapper is required.  (Microsoft has terminated support for
>> versions before IE *11* in January. [1]  We have removed IE 8 support
>> last year [IIRC], and are going to stop actively supporting IE 9 sometime
>> this year.)
> 
> So, you no longer support IE8, but I should?

No.  How did you get that idea?

> Anyway, this is easily fixed by using an additional `false` argument.

Nonsense.  The method itself is not available in the named circumstances.

> Libraries generally take care of that, too.

If they would only do what you suggest, they would be insufficient there.  
Fortunately or not, they do more: they tend to use .attachEvent() then 
(which is not equivalent; I [recommend to] reuse the event-handler property 
instead).

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

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

#30150

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

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

#30161

Stefan Weiss wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Stefan Weiss wrote:
>>>>> - 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

Straw man.

> If this passes as logic for you, it explains a lot. […]

You of all people dare to lecture about logic?  It is an unwritten (and even 
a written, read Aristotle) rule of a *constructive* discussion that those 
who make the claims must substantiate them.  Assuming that those who doubt 
them must do that, or that they must prove that the opposite is true, is 
actually *your* fallacy: shifting the burden of proof.  And you have 
committed this fallacy not only once here.

Insofar you *are* wasting your time.  You are wasting it winding around the 
issue, arguing solely based on supposition.  And *I* am not going to waste 
*my* time on *that* (hence the snipping).

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

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

#30162

On 31/03/16 15:06, Thomas 'PointedEars' Lahn wrote:
> Stefan Weiss wrote:
> 
>> Thomas 'PointedEars' Lahn wrote:
>>> Stefan Weiss wrote:
>>>>>> - 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
> 
> Straw man.
> 
>> If this passes as logic for you, it explains a lot. […]
> 
> You of all people dare to lecture about logic?  It is an unwritten (and even 
> a written, read Aristotle) rule of a *constructive* discussion that those 
> who make the claims must substantiate them.  Assuming that those who doubt 
> them must do that, or that they must prove that the opposite is true, is 
> actually *your* fallacy: shifting the burden of proof.  And you have 
> committed this fallacy not only once here.
> 
> Insofar you *are* wasting your time.  You are wasting it winding around the 
> issue, arguing solely based on supposition.  And *I* am not going to waste 
> *my* time on *that* (hence the snipping).

On the other hand, you can't keep asking for evidence on about any claim
you don't understand.

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

#30176

Thomas 'PointedEars' Lahn wrote:
> Stefan Weiss wrote:
>> A - statement
>> B - give evidence
>> A - no
>> B - statement is therefore false
> 
> Straw man.

Could have been a voodoo doll...

> You of all people dare to lecture about logic?

Of all people, I dare.

> It is an unwritten (and even a written, read Aristotle) rule of a
> *constructive* discussion that those who make the claims must
> substantiate them.

I have neither the time nor the inclination to spell out the obvious to
you. The "evidence" is trivial and implied in the statement. You can
simply try it out and verify it - voila, evidence.

> Assuming that those who doubt them must do that, or that they must
> prove that the opposite is true, is actually *your* fallacy: shifting
> the burden of proof.

I don't have to prove anything. We both know how identifiers are resolved in
a browser, you're just playing dumb. "Cite evidence" is one of your common
go-to phrases used for distraction, and I'm not falling for it.

> Insofar you *are* wasting your time.  You are wasting it winding around the 
> issue, arguing solely based on supposition.  And *I* am not going to waste 
> *my* time on *that* (hence the snipping).

Since my post contained plenty of concrete counterexamples to your claims,
I suspect that the snipping had a different reason.


- stefan

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

#30143

Stefan Ram wrote:

> Stefan Weiss <krewecherl@gmail.com> writes:
>>Personally, I wouldn't use any of these. I would even go a step in the
>>opposite direction and use the more verbose `addEventListener()` method
>>instead of the DOM-0 style "onload" and "onclick" properties:
>>  window.addEventListener("load", function () {
>>      // etc
>>  });
> 
>   When is it better or worse to use »DOMContentLoaded« instead
>   of »load«?

See below.  Next time, STFW and RTFM.
 
>   When is it better or worse to use »body.« instead of
>   »window.« above?

It is better when there is a “body” variable or property in the scope chain 
whose value is a reference to the same object as the value of 
“document.body”.  Neither the ECMAScript global object nor the host-defined 
window object has a built-in ”body” property.
 
>   I am looking for a »default call« to start my scripts that
>   should make sure that most of what usually is needed for a
>   script has been loaded, and so far I had settled for
> 
> document.addEventListener( "DOMContentLoaded", ...

There is no silver bullet.
 
>   I wonder whether it has been really this way historically:
>   was it an invention of jQuery to use CSS selectors to select
>   elements

No, as a *quick* Web research shows, the initial jQuery release was on 
2006-08-26.

>   and is »querySelector« in DOM4 today really because
>   of the prior art (one might say, »pressure«) of jQuery?

No, Document::querySelector() and Document::querySelectorAll() have been 
introduced with the W3C Selectors API Level 1, which went a W3C 
Recommendation in 2013, but had been implemented before (since Firefox 3.5 
[2009-06] and Safari 3.2 [2008-11-13]).

The first working draft of that specification is of 2006-05-25, three months 
earlier than the first jQuery release.  It introduces D::match() and 
D::matchAll() methods for the same purpose; two working drafts later, on 
2007-10-19, they had been renamed to D::qS() and D::qSA().  So the only 
“pressure” that could have come from jQuery was the “query” in the method 
names.

<https://developer.mozilla.org/en-US/docs/Web/API/Document/querySelector> 
pp.

>>That's shorter (and also uses the "DOMready" event). Loading a huge
>>library for just a few lines of code would be counterproductive, but
>>typically the library gets used for the rest of the code, as well.
> 
>   So, there is a »DOMready«, too!

Only as an abstraction layer of some libraries.

<https://developer.mozilla.org/en-US/docs/Web/Events/DOMContentLoaded>

> Now I have »load«, »DOMContentLoaded« /and/ »DOMready« to choose from!

Unless you need to support IE < 9 or IE 9 in Compatibility Mode, listen to 
“DOMContentLoaded” if you are only interested in the nodes of the document 
tree (mistakenly called “DOM”), and “load” if you want to be pretty sure 
that all referred resources have been loaded and rendered.

Better yet, if possible, instead of listening to the “load” event on the 
body/document/window, listen to the “load” event on the specific element of 
whose loading status you are interested in: historically, the “load” event 
of the body/document/window has sometimes fired even before all referred 
images had been downloaded.

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

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

#30151

Stefan Ram wrote:
>   So, there is a »DOMready«, too! Now I have »load«, 
>   »DOMContentLoaded« /and/ »DOMready« to choose from!

[ I "hoisted" this part of my reply for clarity: ]

Sorry, I meant to write "DOMContentLoaded", not "DOMready".


>   When is it better or worse to use »DOMContentLoaded« instead
>   of »load«?
>
>   When is it better or worse to use »body.« instead of
>   »window.« above?

It depends on what exactly you want to wait for.

"DOMContentLoaded" is fired on the `document` object as soon as the
document is fully parsed and the DOM is ready for modification. It does
not wait for every external asset to finish loading. This event also
bubbles up to `window`.

The window's "load" event only fires when every asset on the page has
finished loading. This may take a long time; for example on a gallery
index page, all thumbnails will have to finish loading before this event
fires. Usually we want to make the UI interactive (by attaching
listeners) before that happens.

The document itself never fires a "load" event, but `document.body` can.
The drawback is that this listener cannot be set before the body exists
(i.e. when running a script in the header).

The relationship between `window.onload`, `<body onload=...>` and
`document.body.onload` is somewhat confusing: in Firefox and IE, there
is only a single callback for all three; setting any one of them
replaces the previous setting. In Chromium, there appear to be two
distinct callbacks: a shared one for `window.onload` and
`document.body.onload`, and a separate one for `<body onload=...>`,
which always runs.

In general, my recommendation would be:

- If you want to execute code as soon as possible, before all assets
  have finished loading, listen for "DOMContentLoaded" on `document`
  (or `window`).

- If you want to execute code when everything has finished loading, use
  `window.onload` OR `<body onload>` OR `document.body.onload`, but only
  one of them.

>   I am looking for a »default call« to start my scripts that
>   should make sure that most of what usually is needed for a
>   script has been loaded, and so far I had settled for
> 
> document.addEventListener( "DOMContentLoaded", ...

Looks fine to me.

>> Most people use libraries to simplify common tasks like event handling
>> and element selection. With one such library, your code might look like
>> this:
> 
>   I would not use jQuery for »simplification« of a specific
>   task in a specific browser, but rather because - as far as
>   I have heard about it - it contains code that already
>   contains several adaptions to specific browsers (and their
>   deficiencies and bugs), so, I'd use it because it can act
>   as a kind of compatibility layer to different browsers.

True, but the focus of OP's question was that his code seemed too
complicated. A comprehensive reply would have to mention libraries.

I chose jQuery as an example because it's the most commonly used, but I
hardly ever use it myself. It was not an endorsement.


- stefan

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

#30152

On 2016-03-28 16:47, Stefan Weiss wrote:
> emf wrote:
>> window.onload = function () {
>>      "use strict";
>>      document.getElementById("start").onclick = function () {
>>          requestFullScreen();
>>          init();
>>      };
>> };
>>
>> I arrived at this solution after deciding to remove any JS code from the
>> HTML code. It works fine, however it looks a little too complicated for
>> my personal taste. Is there a simpler way to write it?
>
> This is pretty typical code for what you're doing. There are a few
> variations that could make it a little more concise, but nothing
> dramatic. For example:
>
> - If you include this script after the element with the ID "start", you
>    don't have to wait for the "load" event before you assign a click
>    handler to the element.
> - Strict mode makes no difference in this particular function, so the
>    "use strict" statement could be left out.
> - Explicitly referring to the `window` object is optional; you could
>    write `onload = function ()...` with the same effect.
>
> Personally, I wouldn't use any of these. I would even go a step in the
> opposite direction and use the more verbose `addEventListener()` method
> instead of the DOM-0 style "onload" and "onclick" properties:
>
>    window.addEventListener("load", function () {
>        // etc
>    });
>
> This allows for more than one listener per target and event type, which
> is particularly useful for the "load" event.
>
> Most people use libraries to simplify common tasks like event handling
> and element selection. With one such library, your code might look like
> this:
>
>    $(function () {
>        $("#start").click(function () {
>            requestFullScreen();
>            init();
>        });
>    });
>
> That's shorter (and also uses the "DOMready" event). Loading a huge
> library for just a few lines of code would be counterproductive, but
> typically the library gets used for the rest of the code, as well.
>
>
> - stefan

Wow! I read through all the long thread my message generated, though, 
sincerely, I could only follow only part of it.

Yes, I'll leave my code as is for now. I had just wondered whether there 
existed a shortcut I hadn't come across.

My current modus operandi is to check my code in JSlint, and follow its 
instructions. And, of course, to consult the experts on this list for 
additional questions.

-- 
It ain't THAT, babe! - A radical reinterpretation
http://emf.neocities.org/bd/itaintmebabe.html

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

#30140

On 28/03/16 09:07, emf wrote:
> The eye exercises at:
> 
> http://emf.neocities.org/ix/ix.html
> 
> are working fine (after I was finally able to upload all the files I
> wanted) My question revers to he function that fires them:
> 
> window.onload = function () {
>     "use strict";
>     document.getElementById("start").onclick = function () {
>         requestFullScreen();
>         init();
>     };
> };
> 
> I arrived at this solution after deciding to remove any JS code from the
> HTML code. It works fine, however it looks a little too complicated for
> my personal taste. Is there a simpler way to write it?

"use strict"

window.addEventListener("DOMContentLoaded", attachListener)

function attachListener ()
{
	document.gelElementById("start").addEventListener(requestEvent)
}

function requestEvent ()
{
	requestFullScreen()
	init()
}

[toc] | [prev] | [standalone]

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

csiph-web