How do I add to an onchange event?

nimhyea · Jan 14, 2008

Hello I was wondering if it was possible to add to an already defined
onchange event without having to re-write it completely.

scenario:
<input type="hidden" name="blah" value="" onChange="alert('hello');">

<script ...>
// want to add "world" alert, but since I still want to see
"hello"...
document.getElementById("blah").onchange = function()
{alert("hello");alert("world");}
</script>

ideally I just want to concatenate like:
document.getElementById("blah").onchange += function()
{alert("world");}

and not worry about what was there, but then I get a javascript error.

Thanks for any help.

Doug Gunnoe · Jan 14, 2008

Hello I was wondering if it was possible to add to an already defined
onchange event without having to re-write it completely.

scenario:
<input type="hidden" name="blah" value="" onChange="alert('hello');">

<script ...>
// want to add "world" alert, but since I still want to see
"hello"...
document.getElementById("blah").onchange = function()
{alert("hello");alert("world");}
</script>

ideally I just want to concatenate like:
document.getElementById("blah").onchange += function()
{alert("world");}

and not worry about what was there, but then I get a javascript error.

Thanks for any help.

Interesting. So I tried it just to see what would happen.

First I tried something similar to what you tried.

<html>
<head>
<script>
function dodo(){
alert('world');
}
function doStuff(){
var btn = document.getElementById('btn1');
btn.onclick += "dodo();"
alert(btn.onclick);
}
</script>
</head>
<body>
<input id='btn1' type="button" onclick="alert('hello');" value="click
me"/>
<br>
<input type="button" onclick="doStuff()" value="click me 1st" />
</body>
</html>

And I get this when the doStuff function runs:

http://polisick.com/test1.png

And it is obvious that will not work, right?

So when I just did this,

<input id='btn1' type="button" onclick="alert('hello');dodo();"
value="click me"/>

Then 'dodo()' is inside the anonymous function like so.

http://polisick.com/test2.png

And I guess the one you did would just be showing something like:

function anonymous(){
alert('hello');
}function(){alert('world')}

So I guess you could do some string manipulation and get that
alert('world') inside the anonymous function. Otherwise, someone else
might have a better idea.

Thomas 'PointedEars' Lahn · Jan 14, 2008

Hello I was wondering if it was possible to add to an already defined
onchange event without having to re-write it completely.

scenario:
<input type="hidden" name="blah" value="" onChange="alert('hello');">

Since this element cannot be edited by the user, and so the `change' event
will never occur for it, the `onChange' attribute (which should be
`onchange') does not make sense here.

That aside:

<script ...>
// want to add "world" alert, but since I still want to see
"hello"...
document.getElementById("blah").onchange = function()
{alert("hello");alert("world");}
</script>

ideally I just want to concatenate like:
document.getElementById("blah").onchange += function()
{alert("world");}

Features of the W3C-DOM and DOM Level 0 should not be combined untested;
always avoid such reference worms. Besides, your element has a name, not an
ID. Only MSHTML is this buggy to not care about that difference.

and not worry about what was there, but then I get a javascript error.

Of course, although "a javascript error" is hardly a viable error
description: http://www.jibbering.com/faq/faq_notes/clj_posts.html#ps1DontWork

First, probably you have been trying to access properties of a non-object
that document.getElementById() returns here.

Second, you have been trying to concatenate (Function) object references; in
the best case you have been trying to assign the equivalent of

document.getElementById("blah").onchange = NaN;

as the Function objects were converted to their Number representations in
the script engine's attempt to satisfy your nonsensical demand.

As for the latter, you were looking for something along the following instead:

var _global = this, f = obj.onchange;

obj.onchange = function(e)
{
if (!e)
{
e = (typeof _global.window != "undefined"
&& typeof window.event != "undefined"
&& window.event);
}

if (f)
{
f(e);
}

// arbitrary additional code
window.alert("world");
};

// break circular reference to avoid memory leaks in IE
obj = null;

I have implemented this approach in the current version of
_addEventListener() (or dhtml.addEventListener()) in
http://PointedEars.de/scripts/dhtml.js as an alternative to MSHTML's buggy
attachEvent() where EventTarget::addEventListener() from W3C DOM Level 2
Events is not available. Comments are welcome.

PointedEars

Doug Gunnoe · Jan 14, 2008

Hello I was wondering if it was possible to add to an already defined
onchange event without having to re-write it completely.

scenario:
<input type="hidden" name="blah" value="" onChange="alert('hello');">

<script ...>
// want to add "world" alert, but since I still want to see
"hello"...
document.getElementById("blah").onchange = function()
{alert("hello");alert("world");}
</script>

ideally I just want to concatenate like:
document.getElementById("blah").onchange += function()
{alert("world");}

and not worry about what was there, but then I get a javascript error.

Thanks for any help.

I messed around with this some more.
The following worked on IE 6. I did not try it on anything else.

<html>
<head>
<script>
function dodo(){
alert('world');
}
function doStuff(){
var btn = document.getElementById('btn1');
var str = btn.onclick;
str = str + '';
str = str.substring(str.indexOf('{') + 1, str.indexOf('}'));
btn.onclick = new Function(str + "dodo();");
}
</script>
</head>
<body>
<input type="button" id="btn1" value="click me"
onclick="alert('hello');" />
<input type="button" value="click me 1st" onclick="doStuff()" />
</body>
</html>

SAM · Jan 15, 2008

(e-mail address removed) a écrit :

Hello I was wondering if it was possible to add to an already defined
onchange event without having to re-write it completely.

scenario:
<input type="hidden" name="blah" value="" onChange="alert('hello');">

Here you'll need id="blah"
if you use getElementById

<script ...>
// want to add "world" alert, but since I still want to see
"hello"...
document.getElementById("blah").onchange = function()
{alert("hello");alert("world");}
</script>

ideally I just want to concatenate like:
document.getElementById("blah").onchange += function()
{alert("world");}

If the problem was to get alert('Hello World)

document.getElementById("blah").onchange = function() {
alert('Hello World');}

If you want to do what you tell, use the addEvent function
(IE + others browsers) :

function addEvent( obj, type, fn ) {
if ( obj.attachEvent ) {
obj['e'+type+fn] = fn;
obj[type+fn] = function(){obj['e'+type+fn]( window.event );}
obj.attachEvent( 'on'+type, obj[type+fn] );
} else
obj.addEventListener( type, fn, false );
}

addEvent(document.getElementById("blah"), 'change',
function(){alert("world");});

nota: that doesn't work with IE Mac nor NC4 ;-)

Not sure that onchange works with an hidden field... ?

AKS · Jan 15, 2008

I have implemented this approach in the current version of
_addEventListener() (or dhtml.addEventListener()) inhttp://PointedEars.de/scripts/dhtml.jsas an alternative to MSHTML's buggy
attachEvent() where EventTarget::addEventListener() from W3C DOM Level 2
Events is not available. Comments are welcome.

result = (o[sHandler] == fListener);

-result- will always be false, but logically it must be true.

Thomas 'PointedEars' Lahn · Jan 15, 2008

AKS said:
I have implemented this approach in the current version of
_addEventListener() (or dhtml.addEventListener()) inhttp://PointedEars.de/scripts/dhtml.jsas an alternative to MSHTML's buggy
attachEvent() where EventTarget::addEventListener() from W3C DOM Level 2
Events is not available. Comments are welcome.

Click to expand...

result = (o[sHandler] == fListener);

-result- will always be false, but logically it must be true.

Thanks. You are correct; that was a relic from the previous version. Fixed
with

var oldListener = o["on" + sEvent];
var newListener = function(e)
{
if (!e)
{
e = (typeof _global.window != "undefined"
&& typeof window.event != "undefined"
&& window.event);
}

if (oldListener)
{
oldListener(e);
}

fListener(e);
};

o[sHandler] = newListener;

result = (o[sHandler] == newListener);

PointedEars

Thomas 'PointedEars' Lahn · Jan 15, 2008

Randy said:
Thomas 'PointedEars' Lahn said the following on 1/14/2008 3:27 PM:

Nonsense. It can be ONCHANGE, onChange, onchange, ONChange, or any other
capitalization you prefer. HTML is not case-sensitive.

That is oversimplified. HTML *attribute names* are case-insensitive.[1]
There are the following -- I think valid -- reasons for my recommendation:

1. Consistent markup.
2. Lowercase text compresses better.
3. Reusing the code will be easier.

YMMV.

PointedEars
___________
[1] http://www.w3.org/TR/html401/types.html#h-6.1

David Mark · Jan 15, 2008

result = (o[sHandler] == fListener);

Click to expand...

-result- will always be false, but logically it must be true.

Click to expand...

Thanks. You are correct; that was a relic from the previous version. Fixed
with

var oldListener = o["on" + sEvent];
var newListener = function(e)
{
if (!e)
{
e = (typeof _global.window != "undefined"
&& typeof window.event != "undefined"
&& window.event);
}

If either of the first two tests fail, e will go from undefined to
false. Also, you first check if window is a property of the Global
Object, then turn right around and refer to the same identifier
implicitly.

This would seem sufficient:

e = e || window.event;

Or if you want to be more explicit:

if (!e && _global.window) {
e = _global.window.event;
}

It is hard to imagine an implementation that would throw an exception
on [[Get]] for the window object. Methods of this (or any host
object) are another story (as we have been over recently.)

Or if you must:

if (!e && typeof _global.window == 'object' && _global.window) {
e = _global.window.event;
}

Or to be really paranoid about host object implementations:

if (!e && typeof _global.window != 'undefined') {
e = _global.window.event;
}

But show me one agent that returns anything other than "object" for
typeof window. If there is one that screwy, who is to say that it
wouldn't return a null value for window or throw a [[Get]] exception
on window.event? The fact that such an agent could exist in the
future is a good argument for encapsulating such tests in a central
function (as we have also been over recently.) Regardless, there is
no surefire way to know if a host object will throw an exception on
evaluation.

Either way, assuming no [[Get]] exceptions, e will be an event object
or undefined (but never false.) Personally, I would use the first
one, possibly checking for the existence of the window object prior to
creating the function (or assigning the global event property as
window and the Global Object share the same scope.) The second option
would be:

e = e || _global.event;

Unless you think that IE8 or newer will give window a different scope
than the Global object (obviously won't happen), then this is
sufficient. Here's hoping that IE8 does away with the ridiculous
global event object altogether.

This snippet appears to be part of a general solution, which should
take into account that elements passed may not reside in the same
frame. Also, expandos are always a bad idea. If you must use them,
you need to check the document.expando property first.

Looking at the file it came from, I see a few other problems.

if (typeof oScript.type != "undefined")
{
oScript.type = sType || "text/javascript";
}

if (typeof oScript.type != "undefined")
{
oScript.type = sType || "text/javascript";
}

That is clearly a copy and paste error.

if (isMethod(typeof aHeads[0].appendChild))

I assume this is a typo and isMethodType was meant.

// makes the method applicable to Document and Element objects
if (!o
&& typeof this.constructor != "undefined"
&& /Document|Element/.test(String(this.constructor)))
{
o = this;
}

You wouldn't augment host objects would you? Regardless, this is pure
evil.

Next line:

if (o && isMethod(typeof o.getElementsByTagName))

Same typo as before I assume.

if (typeof HTMLDocument != "undefined"
&& typeof HTMLDocument.prototype != "undefined")
{
HTMLDocument.prototype.getElementsByTabIndex =
getElementsByTabIndex;
}

if (typeof HTMLElement != "undefined"
&& typeof HTMLElement.prototype != "undefined")
{
HTMLElement.prototype.getElementsByTabIndex = getElementsByTabIndex;
}

OMG. No you didn't.

Your attribute alias map lists rowspan, but not colspan. Both get and
set attribute functions have problems. See the version proposed in
the CWR project. It needs to be revised as I recently fixed a couple
of problems, but it should indicate areas that you need to improve in
your code.

The get and set style property functions don't handle float properly.

The show function is roughly equivalent to Prototype's, which is to
say worthless.

The getParent function is ambiguous as parentNode and parentElement
are not equivalent.

The getAbsPos function is severely lacking. For one it completely
ignores borders.

This looks wrong:

if (typeof _global != "undefined")
{
var _global = this;
}

Perhaps you meant:

if (typeof _global == "undefined")

The test isn't needed anyway.

var dhtml = new DHTML();

Shouldn't this library be a singleton?

Overall, feature testing should be pulled out of the functions and the
repetitive comments should be trimmed. You should run it through
JSLint as minification is to be expected (nobody wants to download all
of those credits.)

Thomas 'PointedEars' Lahn · Jan 17, 2008

David said:
AKS said:

On Jan 15, 1:27 am, Thomas 'PointedEars' Lahn <[email protected]>
wrote:
I have implemented this approach in the current version of
_addEventListener() (or dhtml.addEventListener()) inhttp://PointedEars.de/scripts/dhtml.jsasanalternative to MSHTML's buggy
attachEvent() where EventTarget::addEventListener() from W3C DOM Level 2
Events is not available. Comments are welcome.

result = (o[sHandler] == fListener);

Click to expand...

-result- will always be false, but logically it must be true.

Click to expand...

Thanks. You are correct; that was a relic from the previous version. Fixed
with

var oldListener = o["on" + sEvent];
var newListener = function(e)
{
if (!e)
{
e = (typeof _global.window != "undefined"
&& typeof window.event != "undefined"
&& window.event);
}

Click to expand...

If either of the first two tests fail, e will go from undefined to
false.

You are correct, but I don't think this will make a significant
difference. Both values evaluate to `false' in a boolean expression.

Also, you first check if window is a property of the Global
Object, then turn right around and refer to the same identifier
implicitly.

True, the `_global.' is probably error-prone here. Fixed.

This would seem sufficient:

e = e || window.event;

It would not.

Or if you want to be more explicit:

if (!e && _global.window) {
e = _global.window.event;

}

That assumes that `window' would be a property of the Global Object
which, on second thought, does not need to be the case. I am unsure
as to whether to rely on the former or on the scope chain; I'll stick
with the latter for the time being.

[...]
But show me one agent that returns anything other than "object" for
typeof window. If there is one that screwy, who is to say that it
wouldn't return a null value for window

Good point, thanks. An additional type-converting test was necessary.

or throw a [[Get]] exception on window.event?

There is no such thing as a [[Get]] exception. What are you aiming
at?

[...]
This snippet appears to be part of a general solution, which should
take into account that elements passed may not reside in the same
frame.

It is up to the caller to take that into account. If you have a
suggestion to make, then make it:

Talk is cheap. Show me the code. -- Linus Torvalds

Also, expandos are always a bad idea.

I don't see where a host object would be augmented with a property
here.

If you must use them, you need to check the document.expando property first.

That would be relevant *for MSHTML only* iff a host object would be
*augmented* here.

Looking at the file it came from, I see a few other problems.

if (typeof oScript.type != "undefined")
{
oScript.type = sType || "text/javascript";
}

if (typeof oScript.type != "undefined")
{
oScript.type = sType || "text/javascript";
}

That is clearly a copy and paste error.

Maybe not, however it is fixed now.

if (isMethod(typeof aHeads[0].appendChild))

I assume this is a typo and isMethodType was meant.

As no previous version of the method() in the repository handles the
result of the typeof operation, it would have to be. The library uses
the new isMethod() method now.

// makes the method applicable to Document and Element objects
if (!o
&& typeof this.constructor != "undefined"
&& /Document|Element/.test(String(this.constructor)))
{
o = this;
}

You wouldn't augment host objects would you?

I would augment a prototype object of a host object after careful
feature tests. Why not? The fact that there is a prototype object
conveys the implementor's intention that it be used accordingly, so it
is not reasonable to assume that this would not work.

Regardless, this is pure evil.

The explicit conversion to string was not necessary as
RegExp.prototype.test() already does that; fixed. I can't find
anything evil about this. Care to elaborate?

Next line:

if (o &&isMethod(typeof o.getElementsByTagName))

Same typo as before I assume.
Fixed.

if (typeof HTMLDocument != "undefined"
&& typeof HTMLDocument.prototype != "undefined")
{
HTMLDocument.prototype.getElementsByTabIndex =
getElementsByTabIndex;

}

if (typeof HTMLElement != "undefined"
&& typeof HTMLElement.prototype != "undefined")
{
HTMLElement.prototype.getElementsByTabIndex = getElementsByTabIndex;

}

OMG. No you didn't.

Again, why not?

Your attribute alias map lists rowspan, but not colspan.
Fixed.

Both get and set attribute functions have problems. See the version proposed in
the CWR project.

Maybe later.

It needs to be revised as I recently fixed a couple of problems,
but it should indicate areas that you need to improve in
your code.

So it's only more cheap talk?

The get and set style property functions don't handle float properly.

They do now.

The show function is roughly equivalent to Prototype's, which is to
say worthless.

There is no "show function". If you mean display() or visibility(),
you are mistaken.

The getParent function is ambiguous as parentNode and parentElement
are not equivalent.

When would they not be equivalent?

The getAbsPos function is severely lacking. For one it completely
ignores borders.

I'll look into that later.

This looks wrong:

if (typeof _global != "undefined")
{
var _global = this;

}

Perhaps you meant:

if (typeof _global == "undefined")

Yes, I did; fixed.

The test isn't needed anyway.

Yes, it was.

var dhtml = new DHTML();

Shouldn't this library be a singleton?

No, it should not. A singleton is a concept coming from class-based
inheritance to start with.

Overall, feature testing should be pulled out of the functions and the
repetitive comments should be trimmed.

There was and is going to be a version that has all JSdoc[tm] comments
removed, and there is going to be a documentation written in a markup
language generated from them.

You should run it through JSLint as minification is to be expected (nobody wants to download all
of those credits.)

I have stated what I think about minifiers already. As for the
credits, people will have to download the minimum of them (after the
JSdoc[tm] is removed) because otherwise I could not distribute the
library under the GNU GPL 2.0+.

PointedEars

David Mark · Jan 17, 2008

David said:
David said:

AKS wrote:
On Jan 15, 1:27 am, Thomas 'PointedEars' Lahn <[email protected]>
wrote:
I have implemented this approach in the current version of
_addEventListener() (or dhtml.addEventListener()) inhttp://PointedEars.de/scripts/dhtml.jsasanalternativeto MSHTML's buggy
attachEvent() where EventTarget::addEventListener() from W3C DOM Level 2
Events is not available. Comments are welcome.
result = (o[sHandler] == fListener);
-result- will always be false, but logically it must be true.
Thanks. You are correct; that was a relic from the previous version.. Fixed
with
var oldListener = o["on" + sEvent];
var newListener = function(e)
{
if (!e)
{
e = (typeof _global.window != "undefined"
&& typeof window.event != "undefined"
&& window.event);
}

Click to expand...

Click to expand...

If either of the first two tests fail, e will go from undefined to
false.

Click to expand...

You are correct, but I don't think this will make a significant
difference. Both values evaluate to `false' in a boolean expression.

It's just odd to pass false for e.

Also, you first check if window is a property of the Global
Object, then turn right around and refer to the same identifier
implicitly.

Click to expand...

True, the `_global.' is probably error-prone here. Fixed.

This would seem sufficient:

Click to expand...

e = e || window.event;

Click to expand...

It would not.

Or if you want to be more explicit:

Click to expand...

if (!e && _global.window) {
e = _global.window.event;

Click to expand...

}

Click to expand...

That assumes that `window' would be a property of the Global Object
which, on second thought, does not need to be the case. I am unsure
as to whether to rely on the former or on the scope chain; I'll stick
with the latter for the time being.

[...]
But show me one agent that returns anything other than "object" for
typeof window. If there is one that screwy, who is to say that it
wouldn't return a null value for window

Click to expand...

Good point, thanks. An additional type-converting test was necessary.

or throw a [[Get]] exception on window.event?

Click to expand...

There is no such thing as a [[Get]] exception. What are you aiming
at?

If you really don't know, then you have a very short memory. We
discussed that to death two or three weeks ago. Host objects can do
anything they want on [[Get]], including throwing an exception (like
the href property of a news link.)

[...]
This snippet appears to be part of a general solution, which should
take into account that elements passed may not reside in the same
frame.

Click to expand...

It is up to the caller to take that into account. If you have a
suggestion to make, then make it:

Then that should be documented. Otherwise, find the element's
document (use ownerDocument if available, otherwise loop through its
parentNodes until you hit a document node.) Then find the document's
window using parentWindow or defaultView.

Talk is cheap. Show me the code. -- Linus Torvalds

I don't see where a host object would be augmented with a property
here.

I thought I saw that you were storing an expando on element nodes
somewhere in your event section. I'll have to re-read it if I still
care by the end of this message.

That would be relevant *for MSHTML only* iff a host object would be
*augmented* here.

Yes, so you check if it is undefined or true.

Maybe not, however it is fixed now.

The code so nice you wrote it twice.

if (isMethod(typeof aHeads[0].appendChild))

Click to expand...

I assume this is a typo and isMethodType was meant.

Click to expand...

As no previous version of the method() in the repository handles the
result of the typeof operation, it would have to be. The library uses
the new isMethod() method now.

And what would that be? You know you can't pass the method directly.

I would augment a prototype object of a host object after careful
feature tests. Why not? The fact that there is a prototype object
conveys the implementor's intention that it be used accordingly, so it
is not reasonable to assume that this would not work.

You suddenly recommending such an approach seems highly illogical.

The explicit conversion to string was not necessary as
RegExp.prototype.test() already does that; fixed. I can't find
anything evil about this. Care to elaborate?

Surely you jest. Converting a constructor to a string and then
testing for "Document" or "Element?" What have you done with the real
"PointedEars?"

Again, why not?

Again. You are kidding, right?

Maybe later.

So it's only more cheap talk?

It is code that you would do well to read as your implementation of
get/setAttribute is severely lacking. I am just giving you a heads up
that the posted version is not perfect. I know of at least one typo.
Regardless, it will point in you in the right direction.

They do now.

There is no "show function". If you mean display() or visibility(),
you are mistaken.

The display function. And I am not mistaken. It is worthless.

When would they not be equivalent?

When the parent is not an element. Why would there be two of them in
the first place if they were identical?

I'll look into that later.

Don't bother.

Yes, I did; fixed.

Yes, it was.

No, it should not. A singleton is a concept coming from class-based
inheritance to start with.

You know full-well what I mean.

Overall, feature testing should be pulled out of the functions and the
repetitive comments should be trimmed.

Click to expand...

There was and is going to be a version that has all JSdoc[tm] comments

Cheap talk.

removed, and there is going to be a documentation written in a markup
language generated from them.

More cheap talk. I wouldn't waste too much time packaging this thing.

I have stated what I think about minifiers already. As for the

Yet you crammed the thing full of redundant comments that beg to be
stripped out by a minifier.

credits, people will have to download the minimum of them (after the
JSdoc[tm] is removed) because otherwise I could not distribute the
library under the GNU GPL 2.0+.

Distribute it to whom?

Thomas 'PointedEars' Lahn · Jan 17, 2008

David said:
David said:

[...] Thomas 'PointedEars' Lahn [...] wrote:
[...]
if (!e)
{
e = (typeof _global.window != "undefined"
&& typeof window.event != "undefined"
&& window.event);
}
If either of the first two tests fail, e will go from undefined to
false.

Click to expand...

You are correct, but I don't think this will make a significant
difference. Both values evaluate to `false' in a boolean expression.

Click to expand...

It's just odd to pass false for e.

Do you have a point to make here?

or throw a [[Get]] exception on window.event?

Click to expand...

There is no such thing as a [[Get]] exception. What are you aiming
at?

Click to expand...

If you really don't know, then you have a very short memory. We
discussed that to death two or three weeks ago. Host objects can do
anything they want on [[Get]], including throwing an exception (like
the href property of a news link.)

It has been demonstrated that the behavior of `typeof' for host objects is
somewhat different than just a simple property access, so it is questionable
whether your reasoning even applies here.

[...]
This snippet appears to be part of a general solution, which should
take into account that elements passed may not reside in the same
frame.

Click to expand...

It is up to the caller to take that into account. If you have a
suggestion to make, then make it:

Click to expand...

Then that should be documented. Otherwise, find the element's
document (use ownerDocument if available, otherwise loop through its
parentNodes until you hit a document node.) Then find the document's
window using parentWindow or defaultView.

I don't see a reason to, unless you back that up with a reasonable example.

Yes, so you check if it is undefined or true.

I said *iff*. If you only cared to read ...

The code so nice you wrote it twice.

Goodness forbids you'll ever make a mistake! (*HUALP!*)

if (isMethod(typeof aHeads[0].appendChild))
I assume this is a typo and isMethodType was meant.

Click to expand...

As no previous version of the method() in the repository handles the

Click to expand...

The `()' should have been omitted here; just a reflex

And what would that be?

Use the Source, Luke. It's the method that gets passed an object reference
and a string value to designate the property to be tested which avoids the
redundancy caused by passing the result of the `typeof' operation. I had
that in store for a long time, slightly different though, but the discussion
here convinced me that the approach was OK for most occasions.

You know you can't pass the method directly.

Yes, I've known that long since, much longer than you are posting here.
I really don't have time to be patronized by wannabes like you.

You suddenly recommending such an approach seems highly illogical.

Only if one reads my postings with deliberately narrowed vision. The world
isn't black and white, and I use conditions in some of my statements
accordingly.

Surely you jest. Converting a constructor to a string and then
testing for "Document" or "Element?"

I am not testing for "Document" or "Element", but everything that it
contains. That is how it works in Gecko-based UAs, the only UAs that
support this particular feature to date. "Document" may be contained
in "HTMLDocument", and "Element" is contained in the string representation
of the constructor for any object that implements an element interface
from W3C DOM Level 2 HTML.

What have you done with the real "PointedEars?"

I am here. If you have nothing constructive to say, I suggest you be silent.

It is code that you would do well to read as your implementation of
get/setAttribute is severely lacking. I am just giving you a heads up
that the posted version is not perfect.

There can be no perfect version. Both people and DOMs are not perfect.

I know of at least one typo.

Then name it, for goodness' sake! Or simply shut up.

Regardless, it will point in you in the right direction.

In a comment to my code, which you deem error-prone or even erroneous, you
point me to source code that you imply still contains errors either. What
ridiculous kind of pointer is that -- "find the errors"?

The display function. And I am not mistaken. It is worthless.

It is not, else I would not have written it. Your turn.

When the parent is not an element. Why would there be two of them in
the first place if they were identical?

Your logic is flawed. The first property is specified in the W3C DOM; the
second one is defined only in the MSHTML DOM, and not supported elsewhere.
The MSHTML DOM implements several features of the W3C DOM, including this
one, since version 5.0(1). RTFM.

The only case where a parent node property would not yield a reference to an
element node object is the root node of the document tree. Both property
values are `null' in that case. Probably you are confusing this with
childNodes/children which include text nodes.

You know full-well what I mean.

I know what a singleton is, and it does not apply here. Period.

Overall, feature testing should be pulled out of the functions and the
repetitive comments should be trimmed.

Click to expand...

There was and is going to be a version that has all JSdoc[tm] comments

Click to expand...

Cheap talk.

removed, and there is going to be a documentation written in a markup
language generated from them.

Click to expand...

More cheap talk. I wouldn't waste too much time packaging this thing.

I really don't care anymore what you would do. I only mentioned it to
rectify the false impression you were giving about it.

Yet you crammed the thing full of redundant comments that beg to be
stripped out by a minifier.

The comments are not redundant, else I would not have included them. See
above. And if you had read some of them you would not have had to jump to
this many conclusions here.

credits, people will have to download the minimum of them (after the
JSdoc[tm] is removed) because otherwise I could not distribute the
library under the GNU GPL 2.0+.

Click to expand...

Distribute it to whom?

Having waded through all that destructive irrelevance, I'm sorry now to have
even responded and actually felt obliged to thank you for the sound of your
corrections. As despite my newsreader's killfile I saw your posting while
doing research using Google Groups. I'm sorry for thinking it would
actually be possible to engage in a civilized constructive discussion with
you. I guess eventually I will have to revert the setting again :-(

PointedEars

David Mark · Jan 18, 2008

David said:
David said:

David Mark wrote:
[...] Thomas 'PointedEars' Lahn [...] wrote:
[...]
if (!e)
{
e = (typeof _global.window != "undefined"
&& typeof window.event != "undefined"
&& window.event);
}
If either of the first two tests fail, e will go from undefined to
false.
You are correct, but I don't think this will make a significant
difference. Both values evaluate to `false' in a boolean expression.

Click to expand...

Click to expand...

It's just odd to pass false for e.

Click to expand...

Do you have a point to make here?

Yes and I made it.

or throw a [[Get]] exception on window.event?
There is no such thing as a [[Get]] exception. What are you aiming
at?

Click to expand...

Click to expand...

If you really don't know, then you have a very short memory. We
discussed that to death two or three weeks ago. Host objects can do
anything they want on [[Get]], including throwing an exception (like
the href property of a news link.)

Click to expand...

It has been demonstrated that the behavior of `typeof' for host objects is
somewhat different than just a simple property access, so it is questionable
whether your reasoning even applies here.

Not really.

[...]
This snippet appears to be part of a general solution, which should
take into account that elements passed may not reside in the same
frame.
It is up to the caller to take that into account. If you have a
suggestion to make, then make it:

Click to expand...

Click to expand...

Then that should be documented. Otherwise, find the element's
document (use ownerDocument if available, otherwise loop through its
parentNodes until you hit a document node.) Then find the document's
window using parentWindow or defaultView.

Click to expand...

I don't see a reason to, unless you back that up with a reasonable example.

I already gave you the example (the passed element may reside in
another frame.)

I said *iff*. If you only cared to read ...

I was replying to the *for MSHTML only* part. Whether you are
actually setting expandos or not is irrelevant to that particular
comment.

The code so nice you wrote it twice.

Click to expand...

Goodness forbids you'll ever make a mistake! (*HUALP!*)

if (isMethod(typeof aHeads[0].appendChild))
I assume this is a typo and isMethodType was meant.
As no previous version of the method() in the repository handles the

Click to expand...

Click to expand...

The `()' should have been omitted here; just a reflex

And what would that be?

Click to expand...

Use the Source, Luke. It's the method that gets passed an object reference
and a string value to designate the property to be tested which avoids the

Ah, I see. So after all of the arguing against my "isHostMethod"
function, you finally realized it made more sense than your
"isMethodType" function and changed it accordingly. Glad I could
help.

redundancy caused by passing the result of the `typeof' operation. I had
that in store for a long time, slightly different though, but the discussion
here convinced me that the approach was OK for most occasions.

Yes, I've known that long since, much longer than you are posting here.
I really don't have time to be patronized by wannabes like you.

Oh brother. It's the old "I've been posting much longer than you"
argument. And who on earth would "wannabe" you?

Only if one reads my postings with deliberately narrowed vision. The world
isn't black and white, and I use conditions in some of my statements
accordingly.

Here you used conditions to augment HTMLElement and you know that
won't work in IE. That makes for a lopsided interface.

I am not testing for "Document" or "Element", but everything that it
contains. That is how it works in Gecko-based UAs, the only UAs that
support this particular feature to date. "Document" may be contained

Exactly. That's one of the reasons it is a silly thing to do.

in "HTMLDocument", and "Element" is contained in the string representation
of the constructor for any object that implements an element interface
from W3C DOM Level 2 HTML.

Seems to me that there is no guarantee of that.

I am here. If you have nothing constructive to say, I suggest you be silent.

LOL. Count the number of times you said "fixed" in the last post.

There can be no perfect version. Both people and DOMs are not perfect.

The last revision I posted to the CWR Trac server (before it went down
over the holidays) was pretty close. I have tried to add a couple of
revisions since, but the server has been down.

Then name it, for goodness' sake! Or simply shut up.

Good luck with that attitude. I will post my revisions when the
server comes back up (it is down at the moment.)

In a comment to my code, which you deem error-prone or even erroneous, you
point me to source code that you imply still contains errors either. What
ridiculous kind of pointer is that -- "find the errors"?

Everything is relative. Your entire approach is flawed. The proposed
code in the CWR ticket will certainly illustrate why that is,
regardless of any minor defects it may have. IIRC, the typo that
(may) still exist in that ticket is in a regular expression and does
not break anything (it just makes it slightly less consistent.)

It is not, else I would not have written it. Your turn.

I'll pass on that one.

Your logic is flawed. The first property is specified in the W3C DOM; the
Yes.

second one is defined only in the MSHTML DOM, and not supported elsewhere.
Right.

The MSHTML DOM implements several features of the W3C DOM, including this
one, since version 5.0(1). RTFM.

I dom't have to. I know the MSHTML DOM implements parentNode and
parentElement.

The only case where a parent node property would not yield a reference to an
element node object is the root node of the document tree. Both property
values are `null' in that case. Probably you are confusing this with

Wrong. The HTML element will yield a document node object with
parentNode. It yields null with parentElement (as would be expected
as a document node is not an element.) RTFM indeed.

childNodes/children which include text nodes.

Hardly. And of course, childNodes and children are not equivalent
either. The latter returns element and comment nodes only. The
former includes text nodes.

I know what a singleton is, and it does not apply here. Period.

Of course it does. You are side-stepping the issue. Your DHTML
constructor should simply be an object literal (as if you didn't
understand that in the first place.)

Overall, feature testing should be pulled out of the functions and the
repetitive comments should be trimmed.
There was and is going to be a version that has all JSdoc[tm] comments

Click to expand...

Click to expand...

Cheap talk.

Click to expand...

More cheap talk. I wouldn't waste too much time packaging this thing.

Click to expand...

I really don't care anymore what you would do. I only mentioned it to
rectify the false impression you were giving about it.

Pardon? If the impressions I gave were false, why did you have to fix
so many things as a result? A less socially challenged person would
be grateful that I took the time to help them.

The comments are not redundant, else I would not have included them. See

LOL. Does every function need to have Author:"PointedEars" above it?

above. And if you had read some of them you would not have had to jump to
this many conclusions here.

Clearly I jumped to no conclusions, else my comments wouldn't have
generated so many bug fixes.

credits, people will have to download the minimum of them (after the
JSdoc[tm] is removed) because otherwise I could not distribute the
library under the GNU GPL 2.0+.

Click to expand...

Click to expand...

Distribute it to whom?

Click to expand...

Having waded through all that destructive irrelevance, I'm sorry now to have
even responded and actually felt obliged to thank you for the sound of your
corrections. As despite my newsreader's killfile I saw your posting while
doing research using Google Groups. I'm sorry for thinking it would
actually be possible to engage in a civilized constructive discussion with
you. I guess eventually I will have to revert the setting again :-(

Do your worst.

nimhyea · Jan 19, 2008

My goodness! So many options to consider! The addEvent was generally
the option I was hoping for and doug's method has a new DIY charm
about it. The extra discussion that this question spring boarded is
rather interesting and I'll need to ponder it further to fully
understand what's going on there. Thanks everyone!

Doug Gunnoe · Jan 19, 2008

My goodness! So many options to consider! The addEvent was generally
the option I was hoping for and doug's method has a new DIY charm
about it. The extra discussion that this question spring boarded is
rather interesting and I'll need to ponder it further to fully
understand what's going on there. Thanks everyone!

lol. Thanks. 'DIY charm' is the nicest way I have ever heard to call
something a hack.

But hey, sometimes "it works" works, right?

How do I push into an array using an event listener?	5	Dec 22, 2022
How can I add arrows to my FAQ	0	Aug 9, 2023
I am trying to make an audio player, how do I get the selected file to be playable?	5	Mar 29, 2022
nicEdit and onchange	7	Jun 16, 2009
How can I hide a div using an event listener on multiple checkboxes?	6	Dec 23, 2022
How can I add React 18 to existing HTML?	2	Mar 27, 2023
How do I hide the modal after 5 seconds?	4	Jun 1, 2023
How to treat an input data as variable?	4	Apr 13, 2023

How do I add to an onchange event?

nimhyea

Doug Gunnoe

Thomas 'PointedEars' Lahn

Doug Gunnoe

SAM

AKS

Thomas 'PointedEars' Lahn

Thomas 'PointedEars' Lahn

David Mark

Thomas 'PointedEars' Lahn

David Mark

Thomas 'PointedEars' Lahn

David Mark

nimhyea

Doug Gunnoe

Ask a Question

Similar Threads

Members online

Forum statistics

Latest Threads