Here's a big issue, does IE8 support 'this' properly on events now ?
It certainly confuses things if it does !
Aaron
It certainly confuses things if it does !
Aaron
-
-
Re: Does IE8 support 'this' properly on events now ?
Aaron Gray wrote:Support by beta versions or lack thereof is never a big issue.Here's a big issue, does IE8 support 'this' properly on events now ?
IE 8 is certainly irrelevant at this point. If you are interested in itIt certainly confuses things if it does !
without having to update, there is IETester.
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>
-
Re: Does IE8 support 'this' properly on events now ?
"Thomas 'PointedEars' Lahn" <PointedEars@we b.dewrote in message
news:48830E9E.2 060602@PointedE ars.de...Thanks (not sure of the quality of the app though).Aaron Gray wrote:>>Here's a big issue, does IE8 support 'this' properly on events now ?
Support by beta versions or lack thereof is never a big issue.
>>>It certainly confuses things if it does !
IE 8 is certainly irrelevant at this point. If you are interested in it
without having to update, there is IETester.
Aaron
Comment
-
Re: Does IE8 support 'this' properly on events now ?
On Jul 20, 11:10 am, "Aaron Gray" <ang.use...@gma il.comwrote:The inference here is that IE's setting of the value of a listener'sHere's a big issue, does IE8 support 'this' properly on events now ?
this keyword (presumably added using attachEvent) is not proper (or
wrong), however, there is limited circumstantial evidence to support
that assertion.
IE's behaviour in this regard is inconsistent with its behaviour for
listeners assigned to an element's on<eventpropert y directly,
however its behaviour is consistent with in-line listeners as
implemented by all browsers (as far as I know).
You might call that inconvenient, but it isn't improper in the sense
of being wrong.
Only if the change breaks code designed to work with IE's currentIt certainly confuses things if it does !
implementation. I don't think it will, though it might result in
handlers being attached inefficiently (i.e. they might end up using
call or apply where it isn't necessary).
The logical way for IE to support the W3C event model is to implement
addEventListene r according to the W3C DOM 3 specification and leave
attachEvent as it is (though I think the chance of that happening is
very small).
Provided normalising "addEvent"-type functions test for
addEventListene r first, I don't see any issues at all, do you?
--
Rob
Comment
-
Re: Does IE8 support 'this' properly on events now ?
On Jul 20, 7:51 pm, RobG <rg...@iinet.ne t.auwrote:the thisArg in a legacy event is the object the event was attached toOn Jul 20, 11:10 am, "Aaron Gray" <ang.use...@gma il.comwrote:
>>Here's a big issue, does IE8 support 'this' properly on events now ?
The inference here is that IE's setting of the value of a listener's
this keyword (presumably added using attachEvent) is not proper (or
wrong), however, there is limited circumstantial evidence to support
that assertion.
>
IE's behaviour in this regard is inconsistent with its behaviour for
listeners assigned to an element's on<eventpropert y directly,
however its behaviour is consistent with in-line listeners as
implemented by all browsers (as far as I know).
>
in all browsers:
document.body.o nclick = function() { alert(this.tagN ame); };
alert "BODY"
This isn't true for attribute on body in Firefox, due to a bug.
<body onclick="alert( this === windopw)">
FF: alert "true", same as window.onclick in FF
I agree with that. Having a half-assed hybrid MSIE/DOM Event-full-of-The logical way for IE to support the W3C event model is to implement
addEventListene r according to the W3C DOM 3 specification and leave
attachEvent as it is (though I think the chance of that happening is
very small).
bugs would be a serious goat-blower.
Garrett
--
RobComment
-
Re: Does IE8 support 'this' properly on events now ?
dhtml wrote:.... that you *know* -- an important difference. That is not to say I knowOn Jul 20, 7:51 pm, RobG <rg...@iinet.ne t.auwrote:>>On Jul 20, 11:10 am, "Aaron Gray" <ang.use...@gma il.comwrote:>The inference here is that IE's setting of the value of a listener's>>Here's a big issue, does IE8 support 'this' properly on events now ?
>this keyword (presumably added using attachEvent) is not proper (or
>wrong), however, there is limited circumstantial evidence to support
>that assertion.
>>
>IE's behaviour in this regard is inconsistent with its behaviour for
>listeners assigned to an element's on<eventpropert y directly,
>however its behaviour is consistent with in-line listeners as
>implemented by all browsers (as far as I know).
the thisArg in a legacy event is the object the event was attached to
in all browsers:
a browser which works differently, however as it is general your statement
is not acceptable this way.
Whether it is a bug remains to be seen, as there is no public specificationdocument.body.o nclick = function() { alert(this.tagN ame); };
>
alert "BODY"
>
This isn't true for attribute on body in Firefox, due to a bug.
supporting your assertion. I would only call it a peculiarity at this point.
Without the typo.<body onclick="alert( this === windopw)">
>
FF: alert "true", same as window.onclick in FF
PointedEars
--
var bugRiddenCrashP ronePieceOfJunk = (
navigator.userA gent.indexOf('M SIE 5') != -1
&& navigator.userA gent.indexOf('M ac') != -1
) // Plone, register_functi on.js:16
Comment
Comment