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

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

Script in <a > tag in IE

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

Contents

  Script in <a  > tag in IE Tim Slattery <Slattery_T@bls.gov> - 2013-02-07 14:32 -0500
    Re: Script in <a  > tag in IE "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2013-02-07 20:47 +0100
      Re: Script in <a  > tag in IE Tim Slattery <Slattery_T@bls.gov> - 2013-02-07 15:08 -0500
        Re: Script in <a  > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-07 21:20 +0100
        Re: Script in <a  > tag in IE SAM <stephanemoriaux.NoAdmin@wanadoo.fr.invalid> - 2013-02-09 16:42 +0100
      Re: Script in <a  > tag in IE Tim Streater <timstreater@greenbee.net> - 2013-02-07 21:30 +0000
        Re: Script in <a  > tag in IE Denis McMahon <denismfmcmahon@gmail.com> - 2013-02-08 07:08 +0000
          Re: Script in <a  > tag in IE Christoph Becker <cmbecker69@gmx.de> - 2013-02-08 16:30 +0100
            Re: Script in <a  > tag in IE Tim Streater <timstreater@greenbee.net> - 2013-02-08 15:41 +0000
    Re: Script in <a  > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-07 21:02 +0100
      Re: Script in <a  > tag in IE Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2013-02-09 00:19 +0100
        Re: Script in <a  > tag in IE Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2013-02-09 00:25 +0100
        Re: Script in <a  > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-09 14:35 +0100
          Re: Script in <a  > tag in IE Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2013-02-09 22:27 +0100
    Re: Script in <a  > tag in IE Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-02-09 20:33 +0100
      Re: Script in <a  > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-10 00:08 +0100
        Re: Script in <a  > tag in IE Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-02-10 00:52 +0100
          Re: Script in <a  > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-10 01:07 +0100
            Re: Script in <a  > tag in IE Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-02-10 01:20 +0100
              Re: Script in <a  > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-10 01:27 +0100
                Re: Script in <a  > tag in IE Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-02-10 01:43 +0100
                  Re: Script in <a  > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-10 13:55 +0100
                    Re: Script in <a  > tag in IE Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-02-10 20:38 +0100
                      Re: Script in <a  > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-10 21:28 +0100
                        Re: Script in <a  > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-10 21:37 +0100
                        Re: Script in <a  > tag in IE Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-02-10 22:56 +0100
                          Re: Script in <a  > tag in IE Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2013-02-11 00:09 +0100
                            Re: Script in <a  > tag in IE Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2013-02-11 00:30 +0100
                            Re: Script in <a  > tag in IE Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-02-11 00:43 +0100
                              Re: Script in <a  > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-11 01:02 +0100
                              Re: Script in <a  > tag in IE Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2013-02-11 01:16 +0100
                                Re: Script in <a  > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-11 01:49 +0100
                                  Re: Script in <a  > tag in IE Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2013-02-11 17:59 +0100
                                    Re: Script in <a  > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-11 18:19 +0100
                                      Re: Script in <a > tag in IE Scott Sauyet <scott.sauyet@gmail.com> - 2013-02-11 13:03 -0800
                                        Re: Script in <a > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-11 22:09 +0100
                                          Re: Script in <a > tag in IE Scott Sauyet <scott.sauyet@gmail.com> - 2013-02-11 13:59 -0800
                                            Re: Script in <a > tag in IE "Richard Cornford" <Richard@litotes.demon.co.uk> - 2013-02-18 00:15 +0000
                                              Re: Script in <a > tag in IE Scott Sauyet <scott.sauyet@gmail.com> - 2013-02-21 12:33 -0800
                                                Re: Script in <a > tag in IE "Richard Cornford" <Richard@litotes.demon.co.uk> - 2013-02-22 00:59 +0000
                                                  Re: Script in <a > tag in IE Scott Sauyet <scott.sauyet@gmail.com> - 2013-02-23 07:54 -0800
                                              Re: Script in <a > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-22 02:00 +0100
                                            Re: Script in <a > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-22 01:12 +0100
                            Re: Script in <a  > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-11 01:38 +0100
                          Re: Script in <a  > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-11 00:48 +0100
                            Re: Script in <a  > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-11 01:09 +0100
                            Re: Script in <a  > tag in IE Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-02-20 00:07 +0100
          Re: Script in <a > tag in IE dhtml <dhtmlkitchen@gmail.com> - 2013-02-11 07:30 -0800

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#18422

W dniu 2013-02-10 01:27, Thomas 'PointedEars' Lahn pisze:
> Cezary Tomczyk wrote:
>
>> W dniu 2013-02-10 01:07, Thomas 'PointedEars' Lahn pisze:
>>> Cezary Tomczyk wrote:
>> [...]
>>>>>> 1. Don't mix behaviours with logic. Move "onclick" outside of element
>>>>>> <a>.
>>>>>
>>>>> You have not said why.  I think there is no good reason why.  That
>>>>> script code here is short enough so that it is maintainable when in an
>>>>> event handler attribute value, and it is only needed when that
>>>>> particular “a”
>>>>> element is needed.  Loading it always would be a waste of resources.
>>>>
>>>> I am referring to:
>>>>
>>>> *
> http://en.wikipedia.org/wiki/Unobtrusive_JavaScript#Separation_of_behavior_from_markup
>>>> *
> http://www.w3.org/wiki/The_principles_of_unobtrusive_JavaScript#Separation_of_structure_and_behaviour
>>>>
>>>> There is a lot of materials in internet about (let's use some keywords)
>>>> "separate behavior content javascript".
>>>>
>>>> Plus ( from my memory :-) ):
>>>>
>>>> * HTML files are bigger by using inline events and are not cached, while
>>>> JavaScript files can be cached by browsers
>>>
>>> Utter nonsense, all of the above.
>>
>> You have not said why.
>
> True, because we have been over this ad nauseam here already.

Hm, it would maybe good to collect all results of previous discussions 
somewhere in FAQ place, you know. I know that writing the same things 
over and over again is a maybe little bit waste of time.

But on the other hand answer like "Utter nonsense, all of the above." 
doesn't contains useful informations. Just make more confuses.

>>>>>> A good example was provided by Thomas Lahn (he's second example).
>>>>> Which “second example” are you referring to?
>>>>
>>>> [...]
>>>>          a.onclick = function () {
>>>>            addAttachments();
>>>>            return false;
>>>>          };
>>>> [...]
>>>>
>>>> which means that attaching method to event could be done, for example,
>>>> in that way. Not by using inline events.
>>> This code is part of an example in which the “a” element is created
>>> dynamically.  It has nothing to do with some misguided idea of
>>> “Unobtrusive JavaScript”.
>>
>> The code contains an fragment of adding event and method. That part I
>> wanted to cite as an example of way how to add events and methods in a
>> proper way. Not by inline events.
>
> My example has nothing to do with that mindbogglingly stupid approach.
> Do not cite it as an example of that.

As you wish.

Could be written like this:

var doAction = function () {
     addAttachments();
     return false;
};

var m = function () {
    var a = document.getElementById('mylinkelement');
    a.onclick = doAction;
};

m();

But let's leave it as is and close this case.

>> Also, I provided links that contains explanations "why not inline events".
>> You do not have to agree with them.
>
> I do not, because they are utter nonsense.

Without any evidences I can not say that you have right. Anyway, let's 
leave it as is.

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

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

#18427

Cezary Tomczyk wrote:

> W dniu 2013-02-10 01:27, Thomas 'PointedEars' Lahn pisze:
>> Cezary Tomczyk wrote:
>>> W dniu 2013-02-10 01:07, Thomas 'PointedEars' Lahn pisze:
>>>> Cezary Tomczyk wrote:
>>> [...]
>>>>>>> 1. Don't mix behaviours with logic. Move "onclick" outside of
>>>>>>> element <a>.
>>>>>>
>>>>>> You have not said why.  I think there is no good reason why.  That
>>>>>> script code here is short enough so that it is maintainable when in
>>>>>> an event handler attribute value, and it is only needed when that
>>>>>> particular “a”
>>>>>> element is needed.  Loading it always would be a waste of resources.
>>>>>
>>>>> I am referring to:
>>>>>
>>>>> *
>> 
http://en.wikipedia.org/wiki/Unobtrusive_JavaScript#Separation_of_behavior_from_markup
>>>>> *
>> 
http://www.w3.org/wiki/The_principles_of_unobtrusive_JavaScript#Separation_of_structure_and_behaviour
>>>>>
>>>>> There is a lot of materials in internet about (let's use some
>>>>> keywords) "separate behavior content javascript".
>>>>>
>>>>> Plus ( from my memory :-) ):
>>>>>
>>>>> * HTML files are bigger by using inline events and are not cached,
>>>>> while JavaScript files can be cached by browsers
>>>> Utter nonsense, all of the above.
>>> You have not said why.
>> True, because we have been over this ad nauseam here already.
> 
> Hm, it would maybe good to collect all results of previous discussions
> somewhere in FAQ place, you know. I know that writing the same things
> over and over again is a maybe little bit waste of time.

Yes.  Thank you for your volunteering.
 
> But on the other hand answer like "Utter nonsense, all of the above."
> doesn't contains useful informations. Just make more confuses.

You can find indication that it is utter nonsense when you evaluate the 
truth value of the statement “HTML files […] by using inline events […] are 
not cached”.  The fact aside that there are no “inline events” (there are 
event-handler attributes on elements, many of them defined in HTML 
Specifications HTML 4.01 [REC] and HTML5 [CR]): *Why* would such a document 
_not_ be cached by an HTTP client?

> Could be written like this:
> 
> var doAction = function () {
>      addAttachments();
>      return false;
> };
> 
> var m = function () {
>     var a = document.getElementById('mylinkelement');
>     a.onclick = doAction;
> };
> 
> m();

Could be, but should not.
 
> But let's leave it as is and close this case.

This is not a matter of opinion.  There are good reasons why this is harder 
to maintain bloat code – directly contradicting your thesis that the 
separation would make a smaller footprint and would make things easier –, 
and there are few if any reasons why it is not.  You can see that when you 
count the number of characters required for implementing either approach.  
You can see it again when you calculate the code distance in either case.  
You can see it yet again when you consider the compatibility of either 
approach.

Your approach can be useful – if augmented – if the same functionality is 
needed in several places and the event does not bubble.  Which is not the 
case here.

>>> Also, I provided links that contains explanations "why not inline
>>> events". You do not have to agree with them.
>> I do not, because they are utter nonsense.
> 
> Without any evidences I can not say that you have right. Anyway, let's
> leave it as is.

No, truth must be told, and you have not thought this through.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#18435

W dniu 2013-02-10 13:55, Thomas 'PointedEars' Lahn pisze:
> Cezary Tomczyk wrote:
>
>> W dniu 2013-02-10 01:27, Thomas 'PointedEars' Lahn pisze:
>>> Cezary Tomczyk wrote:
[...]
>>>> You have not said why.
>>> True, because we have been over this ad nauseam here already.
>>
>> Hm, it would maybe good to collect all results of previous discussions
>> somewhere in FAQ place, you know. I know that writing the same things
>> over and over again is a maybe little bit waste of time.
>
> Yes.  Thank you for your volunteering.

:-) I have created a site based on MediaWiki:

http://faq.jscode.info/index.php/Main_Page

If this can helps then site could be improved by adding new contributors 
and content. Otherwise just say: "Not this time" :-)

>> But on the other hand answer like "Utter nonsense, all of the above."
>> doesn't contains useful informations. Just make more confuses.
>
> You can find indication that it is utter nonsense when you evaluate the
> truth value of the statement “HTML files […] by using inline events […] are
> not cached”.  The fact aside that there are no “inline events” (there are
> event-handler attributes on elements, many of them defined in HTML
> Specifications HTML 4.01 [REC] and HTML5 [CR]): *Why* would such a document
> _not_ be cached by an HTTP client?

Sorry, I went to far. HTML files may of course be cached. I probably had 
some delusions. :-)

>> Could be written like this:
>>
>> var doAction = function () {
>>       addAttachments();
>>       return false;
>> };
>>
>> var m = function () {
>>      var a = document.getElementById('mylinkelement');
>>      a.onclick = doAction;
>> };
>>
>> m();
>
> Could be, but should not.

More or less I agree.

>> But let's leave it as is and close this case.
>
> This is not a matter of opinion.  There are good reasons why this is harder
> to maintain bloat code – directly contradicting your thesis that the
> separation would make a smaller footprint and would make things easier –,
> and there are few if any reasons why it is not.  You can see that when you
> count the number of characters required for implementing either approach.
> You can see it again when you calculate the code distance in either case.
> You can see it yet again when you consider the compatibility of either
> approach.

Well, I never use event-handler attributes on elements. Just separate 
behaviours and logic. For me is just easier for maintenance.

Another thing is when user has no JavaScript* (for whatever reason) then 
HTML code is just slightly bigger to download. Not maybe big difference, 
but it is. Because contains event-handler attributes which will not be 
used when JavaScript is not available.

I wouldn't worry so much about some few kilobytes more in JavaScript 
files. There is more important in my opinion problems like: too much 
requests to server (files are not combined into one file, a lot of 
requests for some data, etc.), not efficient code, files not cached, etc.

> Your approach can be useful – if augmented – if the same functionality is
> needed in several places and the event does not bubble.  Which is not the
> case here.

Hm, this topic should be also in FAQ: "When and when not to use 
event-handler attributes?".

>>>> Also, I provided links that contains explanations "why not inline
>>>> events". You do not have to agree with them.
>>> I do not, because they are utter nonsense.
>>
>> Without any evidences I can not say that you have right. Anyway, let's
>> leave it as is.
>
> No, truth must be told, and you have not thought this through.

Unfortunately, I like evidences instead of trusting :-) Descriptions 
(articles or something similar) that are convincing or examples that works.

* There is no "JavaScript", I know.

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

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

#18436

Cezary Tomczyk wrote:

> W dniu 2013-02-10 13:55, Thomas 'PointedEars' Lahn pisze:
>> Cezary Tomczyk wrote:
>>> W dniu 2013-02-10 01:27, Thomas 'PointedEars' Lahn pisze:
>>>> Cezary Tomczyk wrote:
> [...]
>>>>> You have not said why.
>>>> True, because we have been over this ad nauseam here already.
>>> Hm, it would maybe good to collect all results of previous discussions
>>> somewhere in FAQ place, you know. I know that writing the same things
>>> over and over again is a maybe little bit waste of time.
>> Yes.  Thank you for your volunteering.
> 
> :-) I have created a site based on MediaWiki:
> 
> http://faq.jscode.info/index.php/Main_Page
> 
> If this can helps then site could be improved by adding new contributors
> and content. Otherwise just say: "Not this time" :-)

Thanks but no, thanks.  We have already discussed the problems of a Wiki 
approach; the arguments as to that, and my reasons against that, have not 
changed.  Conclusions reached from discussion which can be mutually agreed 
on should become FAQ Notes, editable only by very few people who can be 
trusted that they would not use their influence to propagate their personal 
opinions, in order to ensure integrity.

Besides, there are many misconceptions waiting to be promoted from reading 
the text that is already there because it is poorly worded and contains 
factual errors.

>>> Could be written like this:
>>>
>>> var doAction = function () {
>>>       addAttachments();
>>>       return false;
>>> };
>>>
>>> var m = function () {
>>>      var a = document.getElementById('mylinkelement');
>>>      a.onclick = doAction;
>>> };
>>>
>>> m();
>>
>> […]
>> This is not a matter of opinion.  There are good reasons why this is
>> harder to maintain bloat code – directly contradicting your thesis that
>> the separation would make a smaller footprint and would make things
>> easier –, and there are few if any reasons why it is not.  You can see
>> that when you count the number of characters required for implementing
>> either approach. You can see it again when you calculate the code
>> distance in either case. You can see it yet again when you consider the
>> compatibility of either approach.
> 
> Well, I never use event-handler attributes on elements.

So much the pity.  I use event-handler attributes whenever there is no 
better alternative, for the already named reasons at least.

> Just separate behaviours and logic.

You are under the delusion that “behavior” and “(business) logic” are 
separate things.  Business logic *is* the behavior of the application; what 
it does when it receives certain input.  Perhaps you meant to say “separate 
presentation and layout” (which can be a reasonable approach, but _not_ /per 
se/); still your confusing that already shows how little you actually 
*understand* of what you are talking about.

> For me is just easier for maintenance.

Each time you edit you will have to switch between the script code and the 
markup, even for tasks that require no more than a one-liner with an event-
handler attribute, and – proven already – considerably more (if done 
properly) with that so-called “unobtrusive JavaScript” approach.  How can 
*greater* code distance and *unnecessarily* *complicated*, *larger* code 
ease maintenance?
 
> Another thing is when user has no JavaScript* (for whatever reason) then
> HTML code is just slightly bigger to download. Not maybe big difference,
> but it is. Because contains event-handler attributes which will not be
> used when JavaScript is not available.

Your logic is flawed.  In general, you need *more* source code if you do not 
use event-handler attributes at all, to make it work reliably.  The user 
needs to download that *larger* code base the *same* as with event-handler 
attributes, *no matter* whether client-side scripting is supported.  
Browsers do not skip downloading script code when client-side script support 
is disabled, because it could be re-enabled afterwards.
 
> I wouldn't worry so much about some few kilobytes more in JavaScript
> files. There is more important in my opinion problems like: too much
> requests to server (files are not combined into one file, a lot of
> requests for some data, etc.), not efficient code, files not cached, etc.

Files (better: resources) are cacheable in both cases.  And you are 
*increasing* the number of requests if you move code to external resources, 
even when not necessary.  Again I ask you: Where is the logic in that?

>>>>> Also, I provided links that contains explanations "why not inline
>>>>> events". You do not have to agree with them.
>>>> I do not, because they are utter nonsense.
>>> Without any evidences I can not say that you have right. Anyway, let's
>>> leave it as is.
>> No, truth must be told, and you have not thought this through.
> 
> Unfortunately, I like evidences instead of trusting :-)

You should not and you do not have to take this on trust; neither should you 
take the statements of anyone else, including Douglas Crockford, on trust or 
even faith.  Look for *well-founded*, *provable* and *proven* arguments, not 
authority.  Keep in mind: An argument from authority is a fallacy, because 
the *assumed* authority can be wrong.  This is probably the best advice that 
can be given in this field where, due to a stream of beginners that think 
they are experts even after a considerably short exposure and experience, 
superficially logical sounding utter nonsense is commonplace.

I have pointed out to you again the evidence that shows why your assumptions 
are wrong, even though they should be obvious to a reasonable person.  All 
you need to do now is accept them so that you can evaluate them.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#18437

Thomas 'PointedEars' Lahn wrote:

> Cezary Tomczyk wrote:
>> Just separate behaviours and logic.
> 
> You are under the delusion that “behavior” and “(business) logic” are
> separate things.  Business logic *is* the behavior of the application;
> what it does when it receives certain input.  Perhaps you meant to say
> “separate presentation and layout” (which can be a reasonable approach,

That should have been “markup”, not “layout”; as in “avoid inline styles
(when not necessary)”.

-- 
PointedEars

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

#18438

W dniu 2013-02-10 21:28, Thomas 'PointedEars' Lahn pisze:
> Cezary Tomczyk wrote:
[...]
>> :-) I have created a site based on MediaWiki:
>>
>> http://faq.jscode.info/index.php/Main_Page
>>
>> If this can helps then site could be improved by adding new contributors
>> and content. Otherwise just say: "Not this time" :-)
>
> Thanks but no, thanks.  We have already discussed the problems of a Wiki
> approach; the arguments as to that, and my reasons against that, have not
> changed.  Conclusions reached from discussion which can be mutually agreed
> on should become FAQ Notes, editable only by very few people who can be
> trusted that they would not use their influence to propagate their personal
> opinions, in order to ensure integrity.
>
> Besides, there are many misconceptions waiting to be promoted from reading
> the text that is already there because it is poorly worded and contains
> factual errors.

Ok.

[...]
>> Well, I never use event-handler attributes on elements.
>
> So much the pity.  I use event-handler attributes whenever there is no
> better alternative, for the already named reasons at least.
>
>> Just separate behaviours and logic.
>
> You are under the delusion that “behavior” and “(business) logic” are
> separate things.  Business logic *is* the behavior of the application; what
> it does when it receives certain input.  Perhaps you meant to say “separate
> presentation and layout” (which can be a reasonable approach, but _not_ /per
> se/); still your confusing that already shows how little you actually
> *understand* of what you are talking about.

Well, I think about exactly what was described in links which I 
specified in one of the previous post.

>> For me is just easier for maintenance.
>
> Each time you edit you will have to switch between the script code and the
> markup, even for tasks that require no more than a one-liner with an event-
> handler attribute, and – proven already – considerably more (if done
> properly) with that so-called “unobtrusive JavaScript” approach.  How can
> *greater* code distance and *unnecessarily* *complicated*, *larger* code
> ease maintenance?

Even, if changes is about "one-liner with an event-handler attribute" 
then I prefer always to make a script code in a separate file. I do not 
want to mix html markup with any script code. It will keep my html 
document clean.

>> Another thing is when user has no JavaScript* (for whatever reason) then
>> HTML code is just slightly bigger to download. Not maybe big difference,
>> but it is. Because contains event-handler attributes which will not be
>> used when JavaScript is not available.
>
> Your logic is flawed.  In general, you need *more* source code if you do not
> use event-handler attributes at all, to make it work reliably.  The user
> needs to download that *larger* code base the *same* as with event-handler
> attributes, *no matter* whether client-side scripting is supported.

I use reusable patterns which means that I do not need every time to 
create separate code for every behaviour. Even, if this will take a few 
lines more it doesn't matter.

Arguments, with which I agree:

http://stackoverflow.com/a/11742769/896702

> Browsers do not skip downloading script code when client-side script support
> is disabled, because it could be re-enabled afterwards.

I created the test page 
http://www.ctomczyk.pl/lab/script_loading/test.html and for example 
Firefox 18.0.2 do not downloading script when scripts are disabled in 
browsers.

>> I wouldn't worry so much about some few kilobytes more in JavaScript
>> files. There is more important in my opinion problems like: too much
>> requests to server (files are not combined into one file, a lot of
>> requests for some data, etc.), not efficient code, files not cached, etc.
>
> Files (better: resources) are cacheable in both cases.  And you are
> *increasing* the number of requests if you move code to external resources,
> even when not necessary.  Again I ask you: Where is the logic in that?

I am not increasing the number of requests if I move code to external 
resources. This only happens while developing. Later all script code are 
combined into one file during build process.

>>>>>> Also, I provided links that contains explanations "why not inline
>>>>>> events". You do not have to agree with them.
>>>>> I do not, because they are utter nonsense.
>>>> Without any evidences I can not say that you have right. Anyway, let's
>>>> leave it as is.
>>> No, truth must be told, and you have not thought this through.
>>
>> Unfortunately, I like evidences instead of trusting :-)
>
> You should not and you do not have to take this on trust; neither should you
> take the statements of anyone else, including Douglas Crockford, on trust or
> even faith.  Look for *well-founded*, *provable* and *proven* arguments, not
> authority.  Keep in mind: An argument from authority is a fallacy, because
> the *assumed* authority can be wrong.  This is probably the best advice that
> can be given in this field where, due to a stream of beginners that think
> they are experts even after a considerably short exposure and experience,
> superficially logical sounding utter nonsense is commonplace.

That conclusion sounds good for me.

> I have pointed out to you again the evidence that shows why your assumptions
> are wrong, even though they should be obvious to a reasonable person.  All
> you need to do now is accept them so that you can evaluate them.

Sometimes I may disagree with some of arguments. Discuss is the best 
option to change the mind.

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

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

#18439

Cezary Tomczyk <cezary.tomczyk@gmail.com> writes:

[event attributes versus DOM*]

> Arguments, with which I agree:
>
> http://stackoverflow.com/a/11742769/896702

| if an event is specified inline, the JS is specified as a string
| (attribute values are always strings) and evaluated when the event
| fires. Evaluation is evil.

Newsflash: event attribute value literals are *not* eval'ed. This BS
theory just seems to keep coming back like a bad song whenever
arguments, common sense and experience are exhausted.

| you are faced with having to reference named functions. This is not
| always ideal (event handlers normally take anonymous functions)

The what? 'Normally', 'event handlers' are objects that implement the
EventListener interface. The fantasy nomenclature for function
declarations and expressions aside, function objects created by event
handlers don't have an identifier, so they should be alright (eyeroll).

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

#18440

Eric Bednarz <bednarz@fahr-zur-hoelle.org> writes:

> [...] function objects created by event handlers

*attributes*

> don't have an identifier, so they should be alright (eyeroll).

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

#18441

W dniu 2013-02-11 00:09, Eric Bednarz pisze:
> Cezary Tomczyk <cezary.tomczyk@gmail.com> writes:
>
> [event attributes versus DOM*]
>
>> Arguments, with which I agree:
>>
>> http://stackoverflow.com/a/11742769/896702
>
> | if an event is specified inline, the JS is specified as a string
> | (attribute values are always strings) and evaluated when the event
> | fires. Evaluation is evil.
>
> Newsflash: event attribute value literals are *not* eval'ed. This BS
> theory just seems to keep coming back like a bad song whenever
> arguments, common sense and experience are exhausted.

I thought that the code is eval'ed :/

> | you are faced with having to reference named functions. This is not
> | always ideal (event handlers normally take anonymous functions)
>
> The what? 'Normally', 'event handlers' are objects that implement the
> EventListener interface. The fantasy nomenclature for function
> declarations and expressions aside, function objects created by event
> handlers don't have an identifier, so they should be alright (eyeroll).

Ok, this source provides more consistent information:
http://www.w3.org/html/wg/drafts/html/master/webappapis.html#event-handler-content-attributes

"7. Set up the script's global object [...]" + "This is typically a 
Window object. In JavaScript, this corresponds to the global object." 
(http://www.w3.org/html/wg/drafts/html/master/webappapis.html#script%27s-global-object)

If I understood it correctly the code inside event-handler attribute is 
executed in global context, right?

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

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

#18444

Cezary Tomczyk wrote:

> W dniu 2013-02-11 00:09, Eric Bednarz pisze:
>> Cezary Tomczyk <cezary.tomczyk@gmail.com> writes:
>> [event attributes versus DOM*]
>>> Arguments, with which I agree:
>>>
>>> http://stackoverflow.com/a/11742769/896702
>>
>> | if an event is specified inline, the JS is specified as a string
>> | (attribute values are always strings) and evaluated when the event
>> | fires. Evaluation is evil.
>>
>> Newsflash: event attribute value literals are *not* eval'ed. This BS
>> theory just seems to keep coming back like a bad song whenever
>> arguments, common sense and experience are exhausted.

ACK.
 
> I thought that the code is eval'ed :/

Apparently there are at least two people who think/thought that.  AISB, 
utter nonsense being told is more the rule than the exception in this field.

[But if I consider postings elsewhere, for example in de.sci.ALL, perhaps 
this is true of any field.  It has always been easier to post nonsense than 
a sound argument.  Insofar it appears to be prudent to limit one's rebuttal 
to the key points so as not to be overwhelmed by nonsense to be refuted.  On 
the other hand, a short, to-the-point rebuttal invites even more nonsense.  
It is a difficult decision.]
 
>> | you are faced with having to reference named functions. This is not
>> | always ideal (event handlers normally take anonymous functions)
>>
>> The what? 'Normally', 'event handlers' are objects that implement the
>> EventListener interface. The fantasy nomenclature for function
>> declarations and expressions aside, function objects created by event
>> handlers don't have an identifier, so they should be alright (eyeroll).
> 
> Ok, this source provides more consistent information:
> http://www.w3.org/html/wg/drafts/html/master/webappapis.html#event-
handler-content-attributes

That is an Editor's Draft.

> "7. Set up the script's global object [...]" + "This is typically a
> Window object. In JavaScript, this corresponds to the global object."
> (http://www.w3.org/html/wg/drafts/html/master/webappapis.html#script%27s-
global-object)

You keep on quoting irrelevant sources.
 
> If I understood it correctly the code inside event-handler attribute is
> executed in global context, right?

Wrong, because the scope chain of that code includes more than the global 
object:

<http://stackoverflow.com/a/9160009/855543>

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#18446

Cezary Tomczyk <cezary.tomczyk@gmail.com> writes:

> W dniu 2013-02-11 00:09, Eric Bednarz pisze:

>> Newsflash: event attribute value literals are *not* eval'ed. This BS
>> theory just seems to keep coming back like a bad song whenever
>> arguments, common sense and experience are exhausted.
>
> I thought that the code is eval'ed :/

| <ul>
|     <li onclick="var quux; alert(delete quux);">Foo</li>
|     <li id="bar">Bar</li>
| </ul>
|  
| <script>
|     document.getElementById('bar').onclick = function () {
|         eval("var quux; alert(delete quux);");
|     };
| </script>

> Ok, this source provides more consistent information:
> http://www.w3.org/html/wg/drafts/html/master/webappapis.html#event-handler-content-attributes
>
> "7. Set up the script's global object [...]" + "This is typically a
> Window object. In JavaScript, this corresponds to the global object."
> (http://www.w3.org/html/wg/drafts/html/master/webappapis.html#script%27s-global-object)
>
> If I understood it correctly the code inside event-handler attribute
> is executed in global context, right?

What do you mean by 'context'? The execution context of the function
body specified with an event attribute literal is the function object
that it creates.

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

#18448

Eric Bednarz wrote:

> Cezary Tomczyk <cezary.tomczyk@gmail.com> writes:
>> W dniu 2013-02-11 00:09, Eric Bednarz pisze:
>>> Newsflash: event attribute value literals are *not* eval'ed. This BS
>>> theory just seems to keep coming back like a bad song whenever
>>> arguments, common sense and experience are exhausted.
>> I thought that the code is eval'ed :/
> 
> | <ul>
> |     <li onclick="var quux; alert(delete quux);">Foo</li>
> |     <li id="bar">Bar</li>
> | </ul>
> |  
> | <script>
> |     document.getElementById('bar').onclick = function () {
> |         eval("var quux; alert(delete quux);");
> |     };
> | </script>

Not that I doubt your conclusions (they are the same as mine), but what 
exactly is this code supposed to prove?

(BTW, please do not use quoting marks with code that is to be tested.  TIA.)
 
>> Ok, this source provides more consistent information:
>> http://www.w3.org/html/wg/drafts/html/master/webappapis.html#event-
handler-content-attributes
>>
>> "7. Set up the script's global object [...]" + "This is typically a
>> Window object. In JavaScript, this corresponds to the global object."
>> (http://www.w3.org/html/wg/drafts/html/master/webappapis.html#script%27s-
global-object)
>>
>> If I understood it correctly the code inside event-handler attribute
>> is executed in global context, right?
> 
> What do you mean by 'context'? The execution context of the function
> body specified with an event attribute literal is the function object

I do not think that “event attribute literal” is proper terminology.
Try “event-handler attribute value” instead.

> that it creates.

An actual object cannot be the abstract entity that is an execution context.  
Probably you meant to say that if and when the function is called, execution 
enters that function's local context (as opposed to the global execution 
context).

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#18458

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

> Eric Bednarz wrote:

>> | <ul>
>> |     <li onclick="var quux; alert(delete quux);">Foo</li>
>> |     <li id="bar">Bar</li>
>> | </ul>
>> |  
>> | <script>
>> |     document.getElementById('bar').onclick = function () {
>> |         eval("var quux; alert(delete quux);");
>> |     };
>> | </script>
>
> Not that I doubt your conclusions (they are the same as mine), but what 
> exactly is this code supposed to prove?

Variables declared in eval code (that isn't in in strict mode) can be
deleted, but I suppose this is a trick question of sorts.

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

#18459

Eric Bednarz wrote:

> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>> Eric Bednarz wrote:
>>> | <ul>
>>> |     <li onclick="var quux; alert(delete quux);">Foo</li>
>>> |     <li id="bar">Bar</li>
>>> | </ul>
>>> |  
>>> | <script>
>>> |     document.getElementById('bar').onclick = function () {
>>> |         eval("var quux; alert(delete quux);");
>>> |     };
>>> | </script>
>>
>> Not that I doubt your conclusions (they are the same as mine), but what
>> exactly is this code supposed to prove?
> 
> Variables declared in eval code (that isn't in in strict mode) can be
> deleted,

ACK.  But nobody said that it would be part of eval code; just that the code 
would be evaluated.

> but I suppose this is a trick question of sorts.

I knew, but did not think of that.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#18460 — Re: Script in <a > tag in IE

Thomas 'PointedEars' Lahn wrote:
> Eric Bednarz wrote:
>
>> Variables declared in eval code (that isn't in in strict mode) can be
>> deleted,
>
> ACK.  But nobody said that it would be part of eval code; just that the code
> would be evaluated.

I'm not clear on the distinction you're making here.  The discussion
has been that the code would be run through `eval`, has it not?  Of
course the code would have to be evaluated in some sense, by some
compiler or interpreter, or it wouldn't do anything.  What distinction
are you drawing here, then?

  -- Scott

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

#18461 — Re: Script in <a > tag in IE

Scott Sauyet wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Eric Bednarz wrote:
>>> Variables declared in eval code (that isn't in in strict mode) can be
>>> deleted,
>>
>> ACK.  But nobody said that it would be part of eval code; just that the
>> code would be evaluated.
> 
> I'm not clear on the distinction you're making here.  The discussion
> has been that the code would be run through `eval`, has it not?

No, it has not.  It has been claimed on Stack Overflow that – in proper 
language – code in event-handler attribute values would be evaluated when 
the event is propagated to the element; Eric's example shows only that it is 
not *eval code*.  Although I do not doubt that the original claim is false – 
there is a Function instance available before the event occurs – those are 
two separate things.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#18462 — Re: Script in <a > tag in IE

Thomas 'PointedEars' Lahn wrote:
> Scott Sauyet wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> Eric Bednarz wrote:
>>>> Variables declared in eval code (that isn't in in strict mode) can be
>>>> deleted,
>
>>> ACK.  But nobody said that it would be part of eval code; just that the
>>> code would be evaluated.
>
>> I'm not clear on the distinction you're making here.  The discussion
>> has been that the code would be run through `eval`, has it not?
>
> No, it has not.  It has been claimed on Stack Overflow that – in proper
> language – code in event-handler attribute values would be evaluated when
> the event is propagated to the element; Eric's example shows only that it is
> not *eval code*.  Although I do not doubt that the original claim is false –
> there is a Function instance available before the event occurs – those are
> two separate things.

Thank you.  Obviously I read the thread in too much of a hurry.  And I
didn't even open the Stack Overflow links.

I've never given much thought to the basic question.  I had done
similar tests to Eric's to prove the same point he made, but I had not
really considered the question of when the Function instances are
created.  I'm quite certain that no sane implementor would create a
new Function instance every time the event listener is needed.  But
beyond that, it's not clear to me whether a lazy instantiation would
be better because the listener might never be called, or if there is
some spin-up time for the compiler that would make it simpler to pre-
compile them all.  And then there is the question of redefining the
event-handler attributes...

Interesting.

  -- Scott

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

#18532 — Re: Script in <a > tag in IE

Scott Sauyet wrote:
> Thomas 'PointedEars' Lahn wrote:
<snip>
>> No, it has not. It has been claimed on Stack Overflow that - in
>> proper language - code in event-handler attribute values would
>> be evaluated when the event is propagated to the element; Eric's
>> example shows only that it is not *eval code*. Although I do not
>> doubt that the original claim is false - there is a Function
>> instance available before the event occurs - those are two separate
>> things.
>
> Thank you.  Obviously I read the thread in too much of a hurry.  And
> I didn't even open the Stack Overflow links.
>
> I've never given much thought to the basic question.  I had done
> similar tests to Eric's to prove the same point he made, but I had
> not really considered the question of when the Function instances are
> created.

If I am remembering correctly then if you did you would find that the 
actual behaviour differs between browsers and has differed over time.

> I'm quite certain that no sane implementor would create a
> new Function instance every time the event listener is needed.

Yes, that would be an odd thing to do.

> But
> beyond that, it's not clear to me whether a lazy instantiation would
> be better because the listener might never be called, or if there is
> some spin-up time for the compiler that would make it simpler to pre-
> compile them all.

Variations in compiler behaviour might be a factor in finding the 
behaviour differing between browsers, but I would suspect that current 
compilers are easily fast enough to get the job  of 
compiling/instantiating g a small function object  done without 
impacting on any user interaction.

The draw back with lazy compilation of intrinsic event attributes (or 
rather the advantage in pre-compiling them) is when you are going to 
shown any error reports relating to possible syntax errors in your 
attribute code. With pre-compiling you will see the errors when the page 
loads (for all of the problematic intrinsic event attributes on that 
page), while with lazy compiling you will only see those errors as the 
individual events are triggered (so they may slip past any less then 
rigorous testing).

And this is the clue to an appropriate test procedure for finding out 
when the intrinsic attribute code is used to create function object; put 
syntax errors in that code and watch for the moments when those syntax 
errors are reported, as it should be at the moment an attempt is made to 
compile the code.

I have tried this (a few years back), and as I remember Firefox and 
Chrome where actually first instantiating the compiling/function objects 
at the moment of reading the, for example, - onclick - property of the 
offending element. That is, it appear to be the getters for the 
intrinsic event properties that were actually creating the function 
object. Which makes more sense than waiting for an actual event needing 
to be handled because it is, in principle, possible for javascript code 
to access the property prior to any events being triggered, but the 
event handling process is still going to have to get the function object 
before it can call it.

> And then there is the question of redefining the
> event-handler attributes...
>
> Interesting.
>

Presumably the test to see if the intrinsic event function was 
re-created each time it was used (called, or the event handling property 
was accessed) would be to store a reference to the function object at 
one point, re-trigger the event and then compare the identity of the 
function stored with the one directly read from element post-event.

Richard.

-- 
Gratuitous third-party plug:-
http://doubtfulnews.com/ 

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

#18586 — Re: Script in <a > tag in IE

Richard Cornford wrote:
> Scott Sauyet wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> No, it has not. It has been claimed on Stack Overflow that - in
>>> proper language - code in event-handler attribute values would
>>> be evaluated when the event is propagated to the element; Eric's
>>> example shows only that it is not *eval code*. Although I do not
>>> doubt that the original claim is false - there is a Function
>>> instance available before the event occurs - those are two separate
>>> things.
>
>> Thank you.  Obviously I read the thread in too much of a hurry.  And
>> I didn't even open the Stack Overflow links.
>
>> I've never given much thought to the basic question.  I had done
>> similar tests to Eric's to prove the same point he made, but I had
>> not really considered the question of when the Function instances are
>> created.
>
> If I am remembering correctly then if you did you would find that the
> actual behaviour differs between browsers and has differed over time.

Obviously with open-source browsers, it's easy enough to find the
truth of the matter if we're interested enough, but it's not clear to
me how you would determine this for other browsers.  I'm simply not
follolwing your suggestion below about the reporting of syntax
errors.  I don't remember seeing errors reported in inline handlers
before they were called, but as I rarely use inline handlers, I don't
really have a strong notion that they wouldn't be.  But even if
they're not reported until later, the parsing of these attributes
might still not run in the same process that parses SCRIPT elements
and reports errors in Javascript programs.  So, while we could
certainly obtain evidence that this parsing is done early, a lack of
that evidence will not imply that it is not done early, as far as I
can tell.

>> I'm quite certain that no sane implementor would create a
>> new Function instance every time the event listener is needed.
>
> Yes, that would be an odd thing to do.

But we both know that some of the implementors out there have done
some fairly odd things over the years...


>> But
>> beyond that, it's not clear to me whether a lazy instantiation would
>> be better because the listener might never be called, or if there is
>> some spin-up time for the compiler that would make it simpler to pre-
>> compile them all.
>
> Variations in compiler behaviour might be a factor in finding the
> behaviour differing between browsers, but I would suspect that current
> compilers are easily fast enough to get the job  of
> compiling/instantiating g a small function object  done without
> impacting on any user interaction.

One, a few, or a few hundred, certainly.  But I can see this being a
usful optimization on a page that has many thousands or tens of
thousands of inline event listener attributes.  There are certainly
still sites written like that, I'm sorry to say.  I wouldn't really
expect it; I simply hadn't given the question any significant
thought.  And I still haven't done any actual research.  :-)


> The draw back with lazy compilation of intrinsic event attributes (or
> rather the advantage in pre-compiling them) is when you are going to
> shown any error reports relating to possible syntax errors in your
> attribute code. With pre-compiling you will see the errors when the page
> loads (for all of the problematic intrinsic event attributes on that
> page), while with lazy compiling you will only see those errors as the
> individual events are triggered (so they may slip past any less then
> rigorous testing).
>
> And this is the clue to an appropriate test procedure for finding out
> when the intrinsic attribute code is used to create function object; put
> syntax errors in that code and watch for the moments when those syntax
> errors are reported, as it should be at the moment an attempt is made to
> compile the code.

I have a very anemic set of browsers on this machine, but I did run
that test on IE8, Chrome 24, and Firefox 10.  IE reports an error on
loading the page.  Chrome and Firefox do not note it on page load.
They note it if I try to invoke the event or if I try to assign a
variable to the value of that element's event handler.  I don't need
to try to invoke the function stored in that variable, simply to make
the assignment:

    <p id="a" onclick="vart x = [};">error here in IE</p>

    // ...
    var p = document.getElementById("a");
    var handler = p.onclick; // error here in Chrome and FF
    handler(); // error here again, of course.


> I have tried this (a few years back), and as I remember Firefox and
> Chrome where actually first instantiating the compiling/function objects
> at the moment of reading the, for example, - onclick - property of the
> offending element. That is, it appear to be the getters for the
> intrinsic event properties that were actually creating the function
> object. Which makes more sense than waiting for an actual event needing
> to be handled because it is, in principle, possible for javascript code
> to access the property prior to any events being triggered, but the
> event handling process is still going to have to get the function object
> before it can call it.

My test confirms your result with Chrome 24 and FF 10.  The behavior
in IE8 is significantly different.


> [ ... ]

Thank you for the interesting information.


> --
> Gratuitous third-party plug:-http://doubtfulnews.com/

I hadn't seen that before.  A lot of fun.  Is this simply a site you
enjoy, or do you have a hand in creating / maintaining it?

  -- Scott

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

#18592 — Re: Script in <a > tag in IE

Scott Sauyet wrote:
> Richard Cornford wrote:
>> Scott Sauyet wrote:
<snip>
>>> I've never given much thought to the basic question. I had done
>>> similar tests to Eric's to prove the same point he made, but I had
>>> not really considered the question of when the Function instances
>>> are created.
>>
>> If I am remembering correctly then if you did you would find that
>> the actual behaviour differs between browsers and has differed
>> over time.
>
> Obviously with open-source browsers, it's easy enough to find the
> truth of the matter if we're interested enough,

And know the language in which it is written and have the time to 
understand the specifics of a complex piece of software.

> but it's not clear
> to me how you would determine this for other browsers.  I'm simply
> not follolwing your suggestion below about the reporting of syntax
> errors.

Interesting, as you appear to have done an entirely serviceable job of 
implanting it below.

> I don't remember seeing errors reported in inline handlers
> before they were called, but as I rarely use inline handlers, I
> don't really have a strong notion that they wouldn't be.

You probably also don't/wouldn't tend put syntax errors , so not seeing 
them reported should not be surprising. However, over the years there 
have been a fair few questions asked on this group where the cause of 
the issue being questioned was syntax errors in intrinsic event 
attribute code. (With one of the more common causes of javascript syntax 
errors being inappropriate HTML entity use (or lack thereof) and/or 
escaping in intrinsic event attribute code.)

> But even
> if they're not reported until later, the parsing of these attributes
> might still not run in the same process that parses SCRIPT elements
> and reports errors in Javascript programs.

Looking back at it I noticed that the last time I tried this Opera was 
not reporting syntax errors in its error console. This represented a 
change from earlier Opera versions which reported those syntax errors as 
the page loaded, from which I concluded that they had switched from 
compiling them as the page loads to lazy compiling them as needed, but 
had filed to sort the error reporting out.

> So, while we could
> certainly obtain evidence that this parsing is done early, a lack of
> that evidence will not imply that it is not done early, as far as I
> can tell.

No, but demonstrating that you can provoke the syntax error report at 
any specific later time by performing a specified actions (such as 
reading a DOM element's pertinent intrinsic event property) can be used 
as evidence that the compiling is being done at that point.  Opera (at 
least in the state it was in when I last tried this) may not be 
providing any positive evidence of how it is behaving in this regard, 
but all of IE, Firefox and Chrome are.

>>> I'm quite certain that no sane implementor would create a
>>> new Function instance every time the event listener is needed.
>>
>> Yes, that would be an odd thing to do.
>
> But we both know that some of the implementors out there have done
> some fairly odd things over the years...

Yes we do :)

>>> But
>>> beyond that, it's not clear to me whether a lazy instantiation
>>> would be better because the listener might never be called, or
>>> if there is some spin-up time for the compiler that would make
>>> it simpler to pre-compile them all.
>>
>> Variations in compiler behaviour might be a factor in finding the
>> behaviour differing between browsers, but I would suspect that
>> current compilers are easily fast enough to get the job of
>> compiling/instantiating a small function object done without
>> impacting on any user interaction.
>
> One, a few, or a few hundred, certainly.  But I can see this being
> a usful optimization on a page that has many thousands or tens of
> thousands of inline event listener attributes.  There are certainly
> still sites written like that, I'm sorry to say.  I wouldn't really
> expect it; I simply hadn't given the question any significant
> thought.  And I still haven't done any actual research.  :-)
>
>> The draw back with lazy compilation of intrinsic event attributes
>> (or rather the advantage in pre-compiling them) is when you are
>> going to shown any error reports relating to possible syntax errors
>> in your attribute code. With pre-compiling you will see the errors
>> when the page loads (for all of the problematic intrinsic event
>> attributes on that page), while with lazy compiling you will only
>> see those errors as the individual events are triggered (so they
>> may slip past any less then rigorous testing).
>>
>> And this is the clue to an appropriate test procedure for finding
>> out when the intrinsic attribute code is used to create function
>> object; put syntax errors in that code and watch for the moments
>> when those syntax errors are reported, as it should be at the
>> moment an attempt is made to compile the code.
>
> I have a very anemic set of browsers on this machine, but I did run
> that test on IE8, Chrome 24, and Firefox 10.  IE reports an error on
> loading the page.

Looking back at what I wrote I notice that I did not remember to mention 
that this is what I was expecting from IE (and it is still the same up 
to at least IE9). In fact it was this extreme that I was alluding to 
when I wrote of "behaviour differs between browsers", and in my opinion 
is a sensible behaviour for a browser as it effetely allows you to 
syntax check all of the intrinsic event attribute code on a page in one 
shot, while the lazy compiling approach needs more hands-on testing to 
achieve the same level of code syntax verification.

This has also been the historic behaviour (including, as I mentioned, 
previous versions of Opera, and in the original versions of 
Mozilla/Firefox). That history possibly gives me a bit of a 
pre-conception prejudice; this is what I see as normal, and the lazy 
compiling is one of those new fangled novelties  ;-)

> Chrome and Firefox do not note it on page load.
> They note it if I try to invoke the event or if I try to assign a
> variable to the value of that element's event handler.

Which I will maintain is specifically the necessary reading of the 
intrinsic event property rather than the actual assignment operation 
(Implying that it is implemented in the getter for the property).

And that is pretty much exactly the test I was proposing.

> I don't need
> to try to invoke the function stored in that variable, simply to
> make the assignment:

Yes, any implied reading of the property should do. That would be 
necessary to facilitate doing things like - if(typeof p.onclick != 
'undefined') - and getting an appropriate result.

>  <p id="a" onclick="vart x = [};">error here in IE</p>
>
>  // ...
>  var p = document.getElementById("a");
>  var handler = p.onclick; // error here in Chrome and FF
>  handler(); // error here again, of course.
>
>
>> I have tried this (a few years back), and as I remember Firefox
>> and Chrome where actually first instantiating the compiling/
>> function objects at the moment of reading the, for example,
>> - onclick - property of the offending element. That is, it appear
>> to be the getters for the intrinsic event properties that were
>> actually creating the function object. Which makes more sense than
>> waiting for an actual event needing to be handled because it is,
>> in principle, possible for javascript code to access the property
>> prior to any events being triggered, but the event handling
>> process is still going to have to get the function object before
>> it can call it.
>
> My test confirms your result with Chrome 24 and FF 10.  The behavior
> in IE8 is significantly different.

Yes, I did intend citing IE's behaviour.

>> [ ... ]
>
> Thank you for the interesting information.
>
>
>> --
>> Gratuitous third-party plug:-
>> http://doubtfulnews.com/
>
> I hadn't seen that before.  A lot of fun.  Is this simply a site
> you enjoy, or do you have a hand in creating / maintaining it?

Third-party means just that. Technically, I think the site is pretty 
much 100% off the shelf software (so not interesting in itself, and 
pretty much what you expect these days). It is a site that I enjoy; for 
the subject(s) covered and the attitude towards them.

-- 
Gratuitous third-party plug:-
http://doubtfulnews.com/ 

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web