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 3 of 3 — ← Prev page 1 2 [3]

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

Richard Cornford wrote:
> 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.

Yes, I did mean that the collective "we" can find out.  I'm assuming
that a group as diverse as the contributors to this ng, for instance,
would probably have among them the requisite skills to discover this
and report to the group, even if one of us in particular didn't
personally didn't know the implementation language of the engine in
question.  But I wasn't really proposing that research.

>> 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 feel as though this technique does not distinguish between an
implementation that parses all the inline event listeners as it parses
the document but doesn't report them unless a request is made for one
and an implementation that doesn't parse them at all until such a
request is made.  Perhaps since there's no real difference to the end
user, the distinction is purely academic, but it's still a somewhat
interesting one to me.

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

Well, I don't do so *intentionally*, but there are times... :-)

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

I guess my test-in-Chrome-first methodology, which replaced my test-in-
Firefox-first one, (and in-Firebird, in-Phoenix, in-Netscape before
that!) means that I may not often run into the difference in behavior
between the browsers.  As soon as I can determine that such a problem
is caused by a common cause and is not browser-specific, I'm not
likely to test in other browsers; or, even if I do, I'm less likely to
pay attention to slight differences in how the error manifests.

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

As I said, I do think there is a third possibility, but there seems to
be no practical way to distinguish it from lazy loading; the only way
to know for sure would be to view the source code.  I know Opera is
switching from their own Presto to the Webkit rendering engine.  I
don't recall what they are going to use for Javascript in the future.

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

It's of course definitive evidence that it's done no later than that
point, but only circumstantial evidence that it is actually performed
then.


> [ ... ]
>>> 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  ;-)

And interestingly, perhaps because I've done more of my web
development since these new-fangled developments arose (I've done web
development since the late 90's, but it's been the center of my career
only since about 2005; and I've done Javascript-only development only
for the last three years), this lazy-loading seems entirely natural to
me.

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

Yes, I'm sure that's the case.


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

Confirmed.

> [ ... ]

  -- Scott

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

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

Richard Cornford wrote:

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

Although it looks as though a DOM implementation's event handler would 
[[Call]] the Function instance that is the event listener, it is actually 
calling code that results from compiling the Function code into either 
bytecode for a Virtual Machine or native machine code.  So it is possible 
that with event-handler attributes no Function instance at all is being 
created unless user code accesses the corresponding event-handler property.  
(AFAIK there is no built-in way to retrieve an event listener added with 
EventTarget::addEventListener().)

In addition to those possible factory-getters, I have learned recently that 
with Chromium/Chrome the issue is even more complex.  By contrast to e. g. 
Mozilla SpiderMonkey, which compiles to and executes bytecode, Google V8 
compiles to and executes native machine code (which I knew before); however, 
I did not know that code generation does not happen before the function is 
called and usually does not happen again (because different code paths are 
handled with hidden classes).  Finally, optimized machine code is being 
generated (once) for objects that are accessed often, so that subsequent 
accesses to them are faster.

See also <http://code.google.com/p/v8/>; I can highly recommend especially 
the second video.

-- 
PointedEars

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

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

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

Scott Sauyet wrote:

> […]  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.

Certainly.  That there is a Function instance when the property is accessed 
does not need to mean that there is also a Function instance when it is not.  
It appears to be prudent that there is a getter that creates the Function 
instance and returns a reference to it not before the property is accessed, 
or there may be a factory that creates the Function instance when the event 
is dispatched to the element.

Insofar one should generally expect event-handler attributes to be more 
efficient than event-handler properties (and their correspondent API 
features) because with the latter the Function instance needs to be created 
first (by the developer).

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

What is the question?

-- 
PointedEars

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

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

#18447

Eric Bednarz wrote:

> Cezary Tomczyk <cezary.tomczyk@gmail.com> writes:
> 
> [event attributes versus DOM*]
> 
>> Arguments, with which I agree:
>>
>> http://stackoverflow.com/a/11742769/896702
> 
> […]
> | 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.

No, that would be event *listeners* which are implemented in user code. 
Event *handlers*, on the other hand, are implemented as built-in code that 
calls added event listeners (per W3C DOM Level 3 Events explicitly, in order 
of addition for an event).  (AISB)

Therefore, you would write

  el.addEventListener(eventType, eventListener, capturing);

to add an event listener for an event type to the represented element or

  el["on" + eventType.toLowerCase()] = eventListener;

to set the primary event listener for that event as non-capturing on the 
represented element.

Event listeners are called by the event handler for an event if they have 
not been removed later, and an event of a matching type is being propagated 
to the element.  As an (AFAIK undocumented) peculiarity of standards-
compliant DOM implementations, the object does not require the handleEvent() 
method of the EventListener interface to be implemented by the user; it 
suffices that the Function instance that is the event listener implements is 
callable, and it is called with the same arguments as handleEvent() would 
have been.  [However, IMHO a DOM event library should augment the Function 
instance with such a method, for maximum compatibility.  
jsx.dom.createEventListener() in JSX:events.js does that.]

The distinction is necessary because before W3C DOM Level 2 Events it was 
not possible to have more than one event listener for an event on an 
element.  (Which is why assigning to a then-proprietary event-handler 
property was often described misleadingly as assigning an “event handler” or 
an “event”, although the actual implementation did not differ much from the 
current ones.  The wrong terminology is [or was] prevalent in the MSDN 
Library.)

<https://developer.mozilla.org/en-US/docs/DOM/EventListener> p.

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

ACK :)

-- 
PointedEars

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

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

#18442

Cezary Tomczyk wrote:

> W dniu 2013-02-10 21:28, Thomas 'PointedEars' Lahn pisze:
>> Cezary Tomczyk wrote:
> [...]
>>> 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.

So, misconceptions by wannabes.

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

That course of action is not indicative of a logical thought process.

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

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

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.

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

You have much to learn.  *All* of the arguments there, without exception, 
are either specious or plain wrong.

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.

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

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

| Evaluation is evil.

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

| - you are faced with having to reference named functions.

That much is true.  However, it is an irrelevant conclusion.  The statement 
is a tautology because at some point a named function needs to be called by 
non-native code *in any case*.

<http://en.wikipedia.org/wiki/Ignoratio_elenchi>

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

<http://en.wikipedia.org/wiki/Red_herring>
 
>> 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.

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.

Here is another example of that: It takes considerably less to write

  <a href="foo"
     onclick="if (typeof event != 'undefined') return bar(event)">…</a>

than to write in the markup

  <script type="text/javascript" src="bar.js"></script>
  …
  <a href="foo" id="baz">…</a>

(or worse) and in script resource bar.js something along the following 
(kids, do not try that at home!):

  window.onload = function () {
    var baz = document.getElementById("baz");
    if (baz)
    {
      var f = function (ev) {
        var ev2 = (typeof ev == "undefined")
                ? (typeof window != "undefined"
                   && typeof window.event != "undefined")
                     ? window.event
                     : null)
                : ev;

        if (ev2)
        {
          bar(ev2);
        }
      };

      var t = typeof baz.addEventListener;
      if (/^\s*unknown\s*$/i.test(t)
          || /^\s*(function|object)\s*$/i.test(t)
             && baz.addEventListener)
      {
        try
        {
          baz.addEventListener("click", f, false);
        }
        catch (e)
        {
          // stub
        }
      }
      else
      {
        try
        {
          baz.onclick = f;
        }
        catch (e)
        {
          // stub
        }
      }
    }
  };

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.

>>> 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. […]

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

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

#18445

Thomas 'PointedEars' Lahn wrote:

> Cezary Tomczyk wrote:
>> W dniu 2013-02-10 21:28, Thomas 'PointedEars' Lahn pisze:
>>> Browsers do not skip downloading script code when client-side script
>>> support is disabled, because it could be re-enabled afterwards.
>> [<http://www.ctomczyk.pl/lab/script_loading/test.html>]
> 
> [<http://en.wikipedia.org/wiki/Circular_reasoning>]
> 
> However, I stand corrected […]
> 
> 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
                                              ^^^^^^^^^^^^^^^
_event-handler attribute values_

> 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.
> 
> Here is another example of that: […]

-- 
PointedEars

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

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

#18574

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/

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

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

On Feb 9, 3:52 pm, Cezary Tomczyk <cezary.tomc...@gmail.com> wrote:
> W dniu 2013-02-10 00:08, Thomas 'PointedEars' Lahn pisze:
>
[...]
> *http://www.w3.org/wiki/The_principles_of_unobtrusive_JavaScript#Separ...
>

Quote:
| This is very easy to do when the script is properly separated from
the
| HTML:
| var x = document.getElementById('somewhereLink');
| if (x) {
|  x.onmouseover = ''x.onfocus ='' hideAll;
|}

Not the greatest example.
--
Garrett

[toc] | [prev] | [standalone]

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

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

csiph-web