single page apps, URL hash setting, bookmarking, & the back button.

[David Mark]

When you look further, you will observe that there are instances where itis
not possible to tell apart a proprietary event-handler property that has
never been assigned a value explicitly from a proprietary event-handler
property that is unsupported.  Not even the strict comparison (which you
have backwards here) changes that.

As a result, I have removed all feature tests to that end from
dhtml.*EventListener() as they would produce false negatives.

He's using shorthand there. See here:

http://thinkweb2.com/projects/prototype/detecting-event-support-without-browser-sniffing/

That works. See my comment at the bottom.

 

[Thomas 'PointedEars' Lahn]

I know that this "technique" is not nearly as robust as I would want it
to be. David's approach (and so my adaptation of it), for example, falls
short on objects which support EventTarget but not Node (i.e. lack
setAttribute), such as `window`.

It really doesn't matter which object is the supposed owner of the
proprietary property.

To work around that, I use an alternative inference with an assumption
that when corresponding event-handler property is not `undefined`, an
event is supported.

Which would be a fatal mistake.

So far, this inference has been quite stable.

Look further. undefined === undefined, null === null.

What does strict comparison have to do with this? I'm using `typeof`
here (together with a string on the RHS), so how could it matter if
`==` or `===` is used?

Because we are talking host objects here?

I assume those are `addEventListener` and `removeEventListener`?
Yes.

I'd be interested to see your implementation of those.

STFW.


PointedEars

 

[Thomas 'PointedEars' Lahn]

It matters which inference you can apply. Of course, you don't have to
rely on any of these in the first place.
Nonsense.


Taking its non-standard nature out of the picture, what makes this
inference a "fatal mistake"?

Wrong question. The non-standard nature is the core of the problem of this
inference.

Sorry, I'm not following.

undefined (unsupported) === undefined (not assigned). Same for `null' and
other false-values, but those are less likely for accesses to unsupported
(read: not implemented) properties.

Do you know of any environments returning non-string value for host
objects' `typeof`? I understand that this is theoretically possible, but
so is it possible for `typeof` to throw error on host objects; Yet, we
don't wrap each of those in a try/catch.

You miss the point.

The one I found was this:

That is not the current one. Maybe I have not posted it yet. FWIW, the
newer versions of these methods do not employ the `typeof' test on
event-handler properties anymore.

[...]
Am I missing something or does this method do nothing in MSHTML DOM,
when given an element with no corresponding event-handler property?

That is what it did, based on the test that was exposed as faulty later.

From what I can see, there's also a circular reference here, although
it's being broken before method returns.

So?


PointedEars