0

There are some posts regarding this theme, but I think the following is not completely clear (at least to me).

What is the difference between

<sometag id="someid" ... onclick="myfunction()"></sometag>

and

<sometag id="someid" ...></sometag>
<script type="text/javascript>
    var element = document.getElementById("someid");
    element.onclick = myfunction;
</script>

?

I know that, in the second case, the function myfunction is called and a paramenter is passed to it, namely a pointer to an object representing the event triggered. In the first case, no parameter is passed. But the question is: Why? I think this difference will be clarified by understanding how the two code blocks above behave.

Another specific question regards the access to the object representing the event triggered. As far as I could check, the only way to access this object, if I use a inline-defined event handler, is through the predefined event object, like in the following code:

<sometag id="someid" ... onclick="myfunction(event)"></sometag>

But it seems that this approach is not standart, that is, the event object does not belong to the DOM/HTML specification, not to say that IE works a bit different. Is that right? Is there another, standard way to access the object representing the triggered event if I use a inline-defined event handler?

I would appreciate answers using plain JavaScript instead of using some library.

Franc
  • 3
  • 2
  • 2
    Both of those ways of assigning event handlers are painfully obsolete. – Pointy Dec 02 '13 at 01:40
  • @Pointy Thank you for your comment. Although I still would like to know the answers to questions above, could you give me some reference to the current practice for event handlers assignment? – Franc Dec 02 '13 at 01:52
  • 1
    I encourage you to read some more modern explanations of how event handling works. [This](https://developer.mozilla.org/en-US/docs/Web/API/EventTarget.addEventListener) is a good start. – Pointy Dec 02 '13 at 03:08
  • @Pointy thank goodness for you. – m59 Dec 02 '13 at 05:02

1 Answers1

1

But the question is: Why?

Because that is how event handling evolved (we're talking Netscape version 2, pre W3C, no useful HTML specification and DOM as a buz word, say 1995). Netscape decided to pass a reference to the event object as the first argument, IE made it available as window.event.

Regarding the event object:

But it seems that this approach is not standart, that is, the event object does not belong to the DOM/HTML specification, not to say that IE works a bit different. Is that right?

Correct. Events were a bit of a mess due to the different event models used in IE and Netscpe (which more–or–less became the W3C event model). There is the W3C DOM Events specification and HTML events, the first covers how they are handled in the DOM, the second how they are applied in the markup.

Essentially the content of an on attribute is treated as script and wrapped in a function that is called per the Events specification.

In the case of using myfunction(event) for an in–line listener, it is certainly standard (as in universally adopted, not as in prescribed in a standard somewhere and is in the W3C HTML spec) and works everywhere. In the IE model, the identifier event resolves to the global window.event, and in the Netscape model to the event object that is created by the handler, so while the models are completely different, the result is the same.

While the following article is not definitive and has some errors, it's pretty good and worth reading: Quriksmode: Introduction to Events.

There is also The World's Most Misunderstood Programming Language Has Become the World's Most Popular Programming Language.

RobG
  • 142,382
  • 31
  • 172
  • 209
  • I'm pretty sure the `event` variable in the inline handler scope was standardized with HTML5. Edit: Indeed, [here it is](http://www.w3.org/TR/html5/webappapis.html#event-handler-content-attributes) – Bergi Dec 02 '13 at 02:22
  • Ah yes, 20 years after it first appeared… :-) I guess I could say HTML5 is a *specification*, not a standard, but I'm sure that somewhere or other it's way to early or late to be splitting hairs. – RobG Dec 02 '13 at 03:53
  • Thank you @RobG and Bergi. Could you explain what is happening in the first case and in the second case to make it clear why they behave different? – Franc Dec 02 '13 at 13:46
  • There is no explanation other than that's how they evolved. The web in general suffered from what Crockford called [premature standardisation](http://javascript.crockford.com/remedial.html). Things were hastily implemented and almost immediately widely used so there was no going back, no one wanted to "break the web". So artifacts from the original development cycle still echo in browsers and on the web. There are many of them, such as making IDs and NAMEs global variables. – RobG Dec 03 '13 at 00:10