On Jul 17, 11:22*am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
> dhtml wrote:
> > On Jul 16, 10:00 pm, RobG <rg...@iinet.net.au> wrote:
> >> On Jul 17, 8:34 am, Peter Michaux <petermich...@gmail.com> wrote:
> >>> On Jul 16, 9:59 am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> >>> 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.

> > 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
2) "proprietary API" - an event registry
3) "host object augmentation" - can be easily avoided

3) "host object augmentation" - this is really just a straw man that
doesn't have much to do with your argument. It's not necessary to
augment host objects to create a registry (though some old browsers
don't support Function.prototype.call(), which can be a pain);

2) "proprietary API" - The event registry becomes necessary when there
is a need for unrelated scripts to add event callbacks to a node.
document.onmousedown and window.onload are common. Some registries
will use attachEvent/addEventListener first, then, if not available,
will fall back to "legacy" DOM 0 style registration.

A registration-adapter function ("addEvent") can be used for native
support of event registration, cross-browser.
An event registry is usually necessary for adding multiple callbacks.

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.

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

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

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/...sher-test.html

It shows right up in Firebug.

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

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

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

[snip]

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

>
> > 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, window.onload is supported in all
browsers and has been in widespread use for a long time. It isn't
going away any time soon.

I don't know how many times I've seen: "when I set onload=, it stopped
working" where the "not working" problem was caused by window.onload
being replaced by a body onload="" attribute (or vice-versa). The
ability to set onload in multiple places can be confusing, at least to
beginners.

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

> >> 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/libr...92(VS.85).aspx
> >http://msdn.microsoft.com/en-us/libr...46(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. What did Microsoft do wrong with
the SCRIPT tag?

> PointedEars