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


Groups > comp.lang.javascript > #18574

Re: Script in <a > tag in IE

From Cezary Tomczyk <cezary.tomczyk@gmail.com>
Newsgroups comp.lang.javascript
Subject Re: Script in <a > tag in IE
Date 2013-02-20 00:07 +0100
Organization Aioe.org NNTP Server
Message-ID <kg10io$ira$2@speranza.aioe.org> (permalink)
References (8 earlier) <1522652.FLkxLQDhY3@PointedEars.de> <kf8svv$sil$1@speranza.aioe.org> <1573878.qxiknB9TEh@PointedEars.de> <kf952n$ned$1@speranza.aioe.org> <9472455.WrvxBpbTlE@PointedEars.de>

Show all headers | View raw


W dniu 2013-02-11 00:48, Thomas 'PointedEars' Lahn pisze:
> Cezary Tomczyk wrote:
[...]
>> I do not want to mix html markup with any script code. It will keep my
>> html document clean.
>
> Since HTML 4.01 at the latest, client-side script code inherently belongs to
> a scripted HTML document.  HTML *includes* the facilities for that in the
> form of “script” elements and event-handler attributes.
>
> <http://www.w3.org/TR/REC-html40/interact/scripts.html>
>
> To force parts apart that belong together so that the resulting code is more
> complex, *no matter what*, is not logical.
>
[...]

>> I use reusable patterns which means that I do not need every time to
>> create separate code for every behaviour.
>
> I can accept that as an general argument in favor of your approach, but …
>
>> Even, if this will take a few lines more it doesn't matter.
>
> … your conclusion is wrong.  It *does* matter, as you can see below.

I think that everyone can do at least in a both ways: 1) using 
event-handler attribute or 2) use addEventListener (attachEvent) to 
register a single event listener on a single target.

By the way: 
https://developer.mozilla.org/en-US/docs/DOM/element.addEventListener#Older_way_to_register_event_listeners

"older way"? Hmm.

>> Arguments, with which I agree:
>>
>> http://stackoverflow.com/a/11742769/896702
>
> You have much to learn.  [...]

There is no such thing as a "I know everything". Every day each of us 
makes mistakes, changes mind and learns. :-)

> See also: <http://en.wikipedia.org/wiki/False_attribution>
>
> | 1) For a long time now there has been a sensible emphasis on a clear split
> |   between content, style and script.
>
> No, there has not; there has been a recommendation by the W3C, through HTML
> 4.01's support for CSS, that *markup* (content) and *presentation* be
> separated when feasible, in order to reuse code and DRY, among other
> advantages:
>
> <http://www.w3.org/TR/REC-html40/present/styles.html>
>
> Even if so, *by whom* has there been an emphasis, *why* does their opinion
> matter, and *why* is that emphasis “sensible”?  This so-called “argument” is
> in fact just theory finding.
>
> <http://en.wikipedia.org/wiki/Thought-terminating_clich%C3%A9#Thought-
> terminating_clich.C3.A9> comes to mind here.

Recommendation doesn't means "must be used in that way".

> | 2) […]
> | - you can bind only one event of each kind with DOM-zero events (which is
> |   what the inline ones are), so you can't have two click event handlers
>
> Wrong (and wrong terminology on top of that – events are not “bound”, for
> example; event *listeners* are *added* for an event).  An event-handler
> attribute value causes the creation of the primary event listener for an
> event on an element.  You can add listeners to that by using (emulations of)
> addEventListener().  BTDT.  This was even true before HTML5, but it is first
> going to be standardized there.

You right. I even created the test: 
http://ctomczyk.pl/lab/event_handler_attribute/test.html to prove it myself.

> | - if an event is specified inline, the JS is specified as a string
> |   (attribute values are always strings) and evaluated when the event
> |   fires.
>
> Wrong.  Source code in event-handler attribute values is being *compiled*
> into a(n anonymous) Function instance as it is parsed (like other script
> code), so that it is available through content attribute properties, like
> “onclick”.  That function is simply *called* when the event is being
> propagated to the element.
>
> With HTML5, those content attribute properties even are going to be
> *standardized* (and are implemented already) as part of the HTML DOM API the
> same as content attributes (event-handler attributes) had been before in
> HTML 4.01.
>
> See also:
>
> <http://www.w3.org/TR/REC-html40/interact/scripts.html#h-18.2.3>
> <http://www.w3.org/TR/DOM-Level-2-HTML/>
> <http://www.w3.org/TR/2012/CR-html5-20121217/webappapis.html#events>

Thanks for explanation.

> | Evaluation is evil.
>
> Now this is *clearly* a thought-terminating cliché (see above).

I even remember my own topic about "eval"-uation.

[...]
> | This is not always ideal (event handlers normally take anonymous
> | functions) and has implications on the function needing to be global
>
> Wrong, those functions do _not_ need to be methods of the Global Object.
> In fact, it is strongly recommended that they not be global, but only
> globally available.

Make sense.

>>> 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.
>
> Your test case is flawed as it is based on circular reasoning.  You cannot
> test *using* scripting whether a script is *downloaded* when script support
> is disabled, which was the point here.  Your test case shows that script
> code is not *executed* when script support is disabled, which nobody doubted
> as it is tautological.
>
> <http://en.wikipedia.org/wiki/Circular_reasoning>
>
> However, I stand corrected (you were in some way faster than me).  After
> posting I have observed this in Chromium “Version 24.0.1312.68 Built on
> Debian wheezy/sid, running on Debian 7.0 (180326)” through the “Network” tab
> of its Developer Tools, and in Iceweasel 18.0.1 through the “Net” tab of
> Firebug 1.11.1.  So it is safe to say that *some* browsers do not download
> script code then.

Yes. That what I meant. There is no 100% guarantee that all browsers 
will not download scripts in above case.

> Still, I do not consider that a sound argument in favor of *unnecessary*
> code separation.  Because the cases I have been talking about contain a
> considerably small amount of script code in event listeners that merely
> calls code located elsewhere, and the resulting code is *in total* still
> smaller when it has the same degree of compatibility as wholly separated
> code.

Maybe in a simple cases using event-handler attributes make sense, but 
in a bigger projects *for me* doesn't make sense at all.

> Here is another example of that: It takes considerably less to write
[...]

(cutted code due to problems with aioe.org)

> That the majority of the latter code is (or should be) implemented as
> library methods (isHostMethod() etc.) does not change the fact that the
> latter code in total is larger and more complex, and still cannot achieve
> the same degree of compatibility as the former code, because it can target
> only known DOM implementations and it reserves an ID (the latter can only be
> worked around with even more complex and potentially incompatible code).
>
> The latter code also does not provide the same user experience as the former
> one because there is no event listener added to the element before the
> document has been *fully* parsed.  If the user activates the element during
> loading, they will experience either the (non-script) fallback approach or a
> malfunction.  That outcome is not acceptable with a *consistent* user
> interface.

Thomas, I didn't said that using event-handler attributes is a wrong 
way. I've just said that I prefer to do it in a separate file. 
Especially, as I said, when I am working on a big project with a big team.

[...]
>> I am not increasing the number of requests if I move code to external
>> resources. […]
>
> Certainly you do.  It is simple arithmetic: In the trivial case, with event-
> handler attributes only *one* HTML resource is required; with “Unobtrusive
> JavaScript” *at least* *two* resources are required: one HTML resource and
> *at least* one script resource.  2 > 1.  So be slow to do that.

True. In trivial case, but mostly I have a more complex cases :-/

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

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


Thread

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

csiph-web