Re: "modern" javascript...

dhtml wrote:
Thomas 'PointedEars' Lahn wrote:
dhtml wrote:
On Jul 16, 10:00 pm, RobG <rg...@xxxxxxxxxxxx> wrote:
On Jul 17, 8:34 am, Peter Michaux <petermich...@xxxxxxxxx> wrote:
On Jul 16, 9:59 am, Thomas 'PointedEars' Lahn <PointedE...@xxxxxx>
wrote:
Joost Diepenmaat wrote:
[...] HTML in scripts is usually a lot harder to maintain than just plain
HTML.
The same can be true for scripts in HTML.
But it is not. That's a straw man argument.

Whether or not it is a straw man isn't something I want to get
sidetracked into. I think we can just discuss the merits/faults of
either approach.

IOW, you are admitting the fallacious argument, and we can ignore it then.
That is fine with me as long as you do not refer to it anymore.

When event handlers are in the HTML, not in the js file, the script is
more scattered. Look in the JS file for that page, not some html/tag
file. Doesn't that seem easier?
It may seem easier at first, but on a closer look one observes how easy
debugging and maintenance is instead hindered by it. In addition to that,
one important drawback of Unobtrusive JavaScript that is frequently
overlooked is that it requires enhanced DOM support, and it may need to
resort to the use of proprietary APIs, and maybe even host object
augmentation (which is pretty bad as support for this is specified as being
optional). Standards-compliant intrinsic event handler attributes seldom
impose such restrictions.

You're talking about a few things here:
1) "enhanced DOM support" - attachEvent/addEventListener

Among others. However, I (and others) have already pointed out several
times that attachEvent() and addEventListener() are in no way equivalent.

2) "proprietary API" - an event registry

Definitely not. I am talking about the `on*' properties, for example.

3) "host object augmentation" - can be easily avoided

Can it? Suppose none of the above is supported, it is not trivial to
determine in a backwards-compatible way whether the object actually has the
property or the attempt at assignment alone would constitute an attempt at
augmentation.

3) "host object augmentation" - this is really just a straw man that
doesn't have much to do with your argument.

It is not, see above.

It's not necessary to augment host objects to create a registry

An event registry is not of much use if adding the primary listener is not
possible already. You would be storing the information but it would not
reflect reality.

(though some old browsers don't support Function.prototype.call(), which
can be a pain);

"Some old browsers" -- that would be all the user agents using MSHTML 5.0 or
before, for example. Do not let yourself also be deceived by so-called Web
statistics.

2) "proprietary API" - The event registry becomes necessary when there
is a need for unrelated scripts to add event callbacks to a node.

I am not debating that.

document.onmousedown and window.onload are common.

Suppose this was the case, they are still proprietary features, inherently
error-prone without a runtime feature test, and so they must be subject to
such a test. Which is not trivial to do.

Why you are referring to `document.onmousedown' is beyond me; it does not
even cover keyboard strokes, while `onclick' does. Much less I understand
the `window.onload' reference; certainly neither is where to mount a
reliable event registry to.

Some registries will use attachEvent/addEventListener first, then, if
not available, will fall back to "legacy" DOM 0 style registration.

Which is a problem in itself; I, for one, have banned attachEvent() from my
library after I learned and observed that the execution order of event
listeners attached like that is arbitrary (and `this' is broken).

A registration-adapter function ("addEvent") can be used for native
support of event registration,

Definitely.

cross-browser.

Definitely not. Or, it depends on how one defines "cross-browser". With
wishful thinking supported by limited experience, it might seem as if the
code would have that property.

An event registry is usually necessary for adding multiple callbacks.

It is necessary for keeping track of them, not for adding them.

If an event registry is used, it can be hard to find the callback that
caused the error in the wrappedFn, but if there is a call stack from
the error, it should contain the function that caused the error.

If there the call stack information is available, one can usually inspect
the event registry object easily.

Some event registries will attempt to use native attachEvent/
addEventListener support, when available, and "legacy" registration
when not available on the object. There are a few problems with that
approach (though that is somewhat of a side topic).

You are repeating yourself.

It is also useful to have a common methodology that is accepted by the
team. Having a restraint like "no event handlers in the HTML" can make
debugging easier.
Having had to debug several such scripts in my job, I seriously doubt that.
To begin with, name a DOM inspector application which shows all the
dynamically added event listeners attached for a target object without
triggering the event, to begin with.

Firebug, for one. Type into the command line:-
document.body.onclick + "";

and see the handler.

I can see the primary listener code then. But that is _not_ what I was
asking for. Read again.

It is true that there is no "getEventListeners" or "getAttachedEvents"
methods.

I also agree that it's less clear if a registry with one "fire" method
is used, however, for this reason, I provided the _callstack property
in APE.EventPublisher. There are two ways to inspect:-

APE.EventPublisher.get(document.body, "onclick").toString();
APE.EventPublisher.get(document.body, "onclick")._callStack;

An error-throwing function is not hard to find:
http://dhtmlkitchen.com/ape/example/event-publisher-test.html

It shows right up in Firebug.

An awful hassle when compared to looking at the plain HTML source code,
don't you think?

Then name one DOM inspector
application that does not show the value of intrinsic event handler
attribute values.

There is no difference if the handler was attached as an attribute vs
external JS in property assignment.

Yes, there is.

<div id="myDiv" onclick="alert(1)">
document.getElementById('myDiv').onclick returns the onclick for
#myDiv

You miss the point. "Unobtrusive JavaScript" ultimately seeks to remove all
event handler attributes from the markup. That is, if something with events
goes wrong that you are not responsible for, and you have to debug it, you
have nothing more than

...<div id="myDiv">...</div>...

and the like.

And then first you need to know that an event listener was actually added
here dynamically, and then you need to find out how it was done, and then
you can, maybe, find the listener code. You will have a really hard time
finding it if it is an anonymous function, if it is (also) wrapped somehow
(think of Prototype.js's infamous bind() method), and especially if it is
also minimized to which these script-kiddie scripts have a strong tendency.
An event registry only helps you there if you know (or can see at a glance)
that there is one and how you can access it. BTDT.

The only difference would be the attachment process: attribute vs
property assignment.

IBTD.

A "bottom script" (I suppose you mean a `script' element at the end of the
`body' element as anything below that would be invalid) is not supposed to
work as the document is not fully loaded.

That's what I mean. What would not be expected to work? Can you
elaborate on that?

You are quoting an obsolete reply, which has been canceled and superseded on
Usenet, and deleted from the Google Groups archive, apparently while you
were writing. The proper one is here: <news:487FD541.1070408@xxxxxxxxxxxxxx>

As for your question: It stands to reason that until the last end tag of the
last element of the document was parsed, one cannot expect the document tree
to be fully mirrored in the DOM. Insofar all attempts at referencing DOM
objects at this point are on a try-and-hope basis, with probably the
exception of the `window' and `document' references as the objects referred
to by them would have to exist by then (if these references are supported).

Slightly more complex: an onload event handler.
Hence this event handler, which should be used through the
standards-compliant attribute of the `body' element (and *not* through the
proprietary property of the Global/window object). What makes it slightly
more complex also has a strong tendency to ease maintenance, because you
will be forced to design the used algorithms top-down (or bottom-up) unless
you want to make a complete illegible mess of the attribute value.

While it might be non-standard,

It is a proprietary DOM feature, no doubt about that.

window.onload is supported in all browsers

You simply cannot know that.

and has been in widespread use for a long time.

So what?

It isn't going away any time soon.

Have you ever considered that it could not be there in the first place?
This newsgroup has even seen a rather disturbing report of window.alert()
not supported by a mobile phone's HTML UA.

Another approach is to capture events on bubble.
Yes, that would be a so far viable and better alternative to Unobtrusive
JavaScript, except when you need to handle proprietary events or events that
do not bubble.

Actually, I should take that back, as it's neither an "alternative to"
nor an "example of" Unobtrusive JavaScript.

It can be part of an alternative to it, and it can be an example of it. But
it can be assumed that few "Unobtrusive JavaScript" lemmings would recognize
the opportunity for the latter; they would rather add the listener to each
and every element that does not bite back instead, and even then.

Then leave the progressive attaching of events to elements up to the
browser - hasta la vista onload!
Microsoft already did that.
http://msdn.microsoft.com/en-us/library/ms535892(VS.85).aspx
http://msdn.microsoft.com/en-us/library/ms533746(VS.85).aspx
But, unsurprisingly, they did it wrong again, i.e. contrary to the markup
standards that they signed up to as a W3C member.

The "for" attribute is proprietary.

No, it is not :)

,-<http://www.w3.org/TR/REC-html40/loose.dtd>
|
| [...]
|
| <!ELEMENT SCRIPT - - %Script; -- script statements -->
| <!ATTLIST SCRIPT
| charset %Charset; #IMPLIED -- char encoding of linked resource --
| type %ContentType; #REQUIRED -- content type of script language --
| language CDATA #IMPLIED -- predefined script language name --
| src %URI; #IMPLIED -- URI for an external script --
| defer (defer) #IMPLIED -- UA may defer execution of script --
| event CDATA #IMPLIED -- reserved for possible future use --
| for %URI; #IMPLIED -- reserved for possible future use --
| >

What did Microsoft do wrong with the SCRIPT tag?

(*Element*, _not_ tag.)

Surprisingly, nothing, apart from the `lang' attribute. My bad.


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
.