Re: Dynamic select lists using optgroups again - without frameworks

Thomas 'PointedEars' Lahn wrote:
First, from the existence of a property or rather its value being
convertible to boolean `true' does not follow necessarily that the property
is a method that can be called. Nor does it follow necessarily from the
non-existence of a property or its value being convertible to boolean
`false' that another property would be available, let alone be a method. So
your feature test is not sufficient, and it makes your code error-prone.
Search the archives for `isMethod' for further information.

Second, both methods are _not_ equivalent. There are a number of problems
with assuming they were, and with attachEvent() itself, see

http://www.quirksmode.org/blog/archives/2005/08/addevent_consid.html

That is indeed an interesting link and stuff that I definitely haven't been aware of.
I didn't even know that Internet Explorer keeps all previously registered events in memory, even when you refresh the page. That explains a few interesting problems I stumbled upon.


Therefore, I have recently suggested a (probably not so new) approach to use
the proprietary event handler property (here: onload) in case
addEventListener() is not available, also supporting several event listeners
for an event an object by emulating the built-in event handler's behavior.
(see <news:478CC039.1060209@xxxxxxxxxxxxxx> and
<news:adf28f78-8090-413b-a518-a699d4f2dcad@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
the thread titled "How do I add to an onchange event?", or search for
"_addEventListener" and my name). The aforementioned Web resource also
provides links to workarounds for this problem that other people have devised.

I think I will find time to look at all these solutions this afternoon, I'm already very curious to see how you have solved it.


Third, `window' refers to a host object that is not formally specified to
implement the EventTarget interface of W3C DOM Level 2 Events. If you would
try to define the listener for the load event with scripting, you would
therefore assign a Function object reference to the `onload' property of the
Window object instead.

And finally, as I said before, "Unobtrusive JavaScript", which is what you
are still following with this, is a misguided approach devised by people who
don't know better. Despite the explanation a paragraph above, you really
don't want to use methods or proprietary properties of equally proprietary
Window objects to define what should happen when the document has been
loaded. Use the fully standards compliant and widely (if not even
universally) supported approach instead:

<body onload="initDynamicSelects()">
...
</body>

You will observe that you also don't need any DOM branching for this. So
not only this is far more more efficient than the former, but also you are
not forced to rely on any specific DOM implementation (and work around the
quirks it might have).

That's indeed nicer than all those strange dom:ready solutions provided by numerous frameworks and scripts, but unfortunately I haven't decided to use "unobstrusive" JavaScript because of idealism, but because I wanted to add and remove certain behaviour just by loading the files or not.
This has a lot to do with the underlying code.

However, wouldn't it be a step into the right direction to give body an id and attach the event listener to that element instead of "window"?


Thank you very much for your verbose answer; I can finally see the reason for your dislike towards those frameworks we talked about earlier and also understood that JS shouldn't be treated as a way to quickly add some eyecandy to your page but wants to be understood.
I promise to give my best to understand it! :-)


-- Pascal Ehlert

.

Relevant Pages

  • Re: Dynamic select lists using optgroups again - without frameworks
    ... convertible to boolean `true' does not follow necessarily that the property ... implement the EventTarget interface of W3C DOM Level 2 Events. ... Window object instead. ... by numerous frameworks and scripts, ...
    (comp.lang.javascript)
  • Re: If...else statement
    ... but could not find the window object in DOM ... DOM standard has ever specified that the ECMAScript global object (or ... as they are the same object in a browser object model) ...
    (microsoft.public.scripting.jscript)
  • Re: Accesing an IFrame from an internal element
    ... More likely because he knows how the DOM works. ... nor the element has a reference to a window object. ... That's a property on the DOM element of the iframe in the parent document, ...
    (comp.lang.javascript)
  • Re: RegExp for hyphen to camelCase?
    ... You could but the global object has never been defined as an instance of the AbstractView interface. ... I would use the slightly longer, ... And the current WHAT WG drafts also try to ensure that the current praxis that browsers implement document.defaultView as the window object becomes standardized: ... in the DOM but to check for the result too. ...
    (comp.lang.javascript)