Mousewheel event does not support DOM0 in FF

[David Mark]

Mousewheel event (DOMMouseScroll) does not support DOM0 in FF, which
means it is undetectable. First one I've seen like that. No big deal
as one should never rely on that event. My advice is to leave it
alone entirely.

 

[Garrett Smith]

Mousewheel event (DOMMouseScroll) does not support DOM0 in FF, which
means it is undetectable. First one I've seen like that. No big deal
as one should never rely on that event. My advice is to leave it
alone entirely.

Others, off the top of my head, include DOMContentLoaded, DOMFocusIn and
DOMFocusOut (not recommended), activation events, mutation events. There
were more but I forgot which ones. Kangax' isEventSupported had issues
regarding body event handlers being added to window.

I've been back and forth with Doug Schepers, specification author for
DOM Events on why dom event detection is important; including my proposal.

The result? He insisted that document.implementation.hasFeature was the
way to go. He complained about me playing an "ego game" by pointing out
that hasFeature sucks.

Now that I am permanently banned, they can carry on with their
dog'n'pony show.

The proposal was basically to make it easier to create and dispatch an
event, as in:

var type = "click",
config = { clientX : 11 },
ev = document.createInitedEvent(type, config);
target.addEventListener(type, f, false);
target.dispatchInitedEvent( ev );

With that, you could create a simple isEventSupported function

Of course if you want to know if something bubbles, or check
relatedTarget, you can pass in those and other options to createInitedEvent.

var ev = document.createInitedEvent("submit", { bubbles : true });
target.parentNode.addEventListener("submit", f, true);

Nobody was able to point out a problem with that, funny thing, but they
seemed to like document.implementation.hasFeature instead.

Garrett

 

[David Mark]

Others, off the top of my head, include DOMContentLoaded,

We've been over that. It doesn't count as it's not for elements.

DOMFocusIn and
DOMFocusOut (not recommended),

See the pattern there.

activation events, mutation events. There

were more but I forgot which ones.

Like the ones that start with "DOM". Apparently those are not
implemented with DOM0 interfaces.

Kangax' isEventSupported had issues
regarding body event handlers being added to window.

LOL. You never stop, do you? Just noticed that my attribute trick
(which is what makes that function work) has been copied by ExtJS
(without crediting anyone), which makes it a clean sweep of the
"major" libraries I think. And yes, most credit the invention to
Kangax.

http://www.cinsoft.net/host.html

I've been back and forth with Doug Schepers, specification author for
DOM Events on why dom event detection is important; including my proposal..

The result? He insisted that document.implementation.hasFeature was the
way to go. He complained about me playing an "ego game" by pointing out
that hasFeature sucks.

Yes, I remember you talking about that. All highly uninteresting to
me as it wouldn't be useful for years. I'm more concerned with now.

Now that I am permanently banned, they can carry on with their
dog'n'pony show.
Whatever.


The proposal was basically to make it easier to create and dispatch an
event, as in:

   var type = "click",
       config = { clientX : 11 },
       ev = document.createInitedEvent(type, config);
   target.addEventListener(type, f, false);
   target.dispatchInitedEvent( ev );

With that, you could create a simple isEventSupported function

Oh screw that. That's what people were trying to do until I came up
with the attribute reflection thing.

Of course if you want to know if something bubbles, or check
relatedTarget, you can pass in those and other options to createInitedEvent.

var ev = document.createInitedEvent("submit", { bubbles : true });
target.parentNode.addEventListener("submit", f, true);

I suppose. If such a thing existed.

Nobody was able to point out a problem with that, funny thing, but they
seemed to like document.implementation.hasFeature instead.

Screw them too.

 

[David Mark]

Others, off the top of my head, include DOMContentLoaded, DOMFocusIn and
DOMFocusOut (not recommended), activation events, mutation events. There
were more but I forgot which ones. Kangax' isEventSupported had issues
regarding body event handlers being added to window.

And what does that last bit mean? Body event handlers being added to
window?

I can only assume you mean testing the load/unload events of the body.
(?) As I've noted (and which may or may not have made it into the
various blogs that discuss the technique), it's not meant to be used
for everything. Why would you even try to detect the load event of
the body (of all things?)

 

[David Mark]

We've been over that.  It doesn't count as it's not for elements.

To be completely accurate, I should have said it is worthless for
elements.

See the pattern there.

activation events, mutation events. There


Like the ones that start with "DOM".  Apparently those are not
implemented with DOM0 interfaces.


LOL.  You never stop, do you?  Just noticed that my attribute trick
(which is what makes that function work) has been copied by ExtJS
(without crediting anyone), which makes it a clean sweep of the
"major" libraries I think.  And yes, most credit the invention to
Kangax.

http://www.cinsoft.net/host.html

Furthermore, it occurs to me that (once again), people are copying and
pasting one of my functions and complaining of "problems" because they
simply don't understand it.

Back when I first schooled you, Peter, etc. on this technique, I am
quite sure I mentioned that it could only reliably detect *DOM0*
support on elements. Inferring anything else (e.g. DOM2 support) was
specifically warned against.

It's pretty funny that scatter-shot observational reports of
"problems" with events that don't support DOM0 at all (and all
starting with the "DOM" prefix) have been trickling in. Stop using
the thing to make bad infernces and you can put the diaries away.

And, could it be that all of these "DOM" prefixed events were
introduced later than DOM0. Check the specs:-

http://www.w3.org/TR/DOM-Level-2-Events/events.html

Yes, what a shock. Case closed.

Note to Kangax, as most people are getting this function from your
blog, please update to stress that inferences about anything other
than DOM0 events are weak. And clearly the ones that are prefixed
with "DOM" are right out.

So what would be a good use of the function? Perhaps if you can spot
touchstart/end, but *not* mousemove, you might implement drag and drop
with touch events (if you are into such things). And to be sure, you
would use the DOM0 interfaces to do it. Why is this a better
example? Because we know mousemove existed in DOM0 and there
certainly won't be a false *positive* regarding the proprietary touch
events.

So, just like with isHost* (and others we've discussed recently) you
actually have to think about what you are doing/testing. These aren't
magic boxes. If you expect to get magical results from them, you will
be disappointed every time. Furthermore, if you think you can write
magic functions, you will fail every time.

HTH

 

[Garrett Smith]

And what does that last bit mean? Body event handlers being added to
window?

I can only assume you mean testing the load/unload events of the body.
(?) As I've noted (and which may or may not have made it into the
various blogs that discuss the technique), it's not meant to be used
for everything. Why would you even try to detect the load event of
the body (of all things?)

Event handler attributes on body causing an event handler being added to
window.

e.g. Detect `focus` event on arbitrary element, as supported in most
modern browsers.

Result: body onfocus attribute causes a focus event handler to be added
to window. I can't remember if removeAttribute caused the window's event
handler to be set to null, but it sounds risky to rely on anything from
that.

There were other issues, but I can't finger them out of my brain ATM.

Garrett

 

[Garrett Smith]

We've been over that. It doesn't count as it's not for elements.


See the pattern there.

activation events, mutation events. There

Like the ones that start with "DOM". Apparently those are not
implemented with DOM0 interfaces.


LOL. You never stop, do you? Just noticed that my attribute trick
(which is what makes that function work) has been copied by ExtJS
(without crediting anyone), which makes it a clean sweep of the
"major" libraries I think. And yes, most credit the invention to
Kangax.

http://www.cinsoft.net/host.html

Having code lifted can seem frustrating -- don't blame me for that and
don't whine. If the idea came from you then state so and make it clear
where the idea came from.

For more information on pitfalls of `isEventSupported` (i'm referring to
kangax' rendition), please see the comments on kangax github project
"isEventSupported". There were more comments in email discussion, as
well. Time permitting, I'll post.

I've not caught up with your other replies, nor those of TPEL.

[...]

Oh screw that. That's what people were trying to do until I came up
with the attribute reflection thing.

People were trying a proposal as if it had been implemented? That seems
very strange. It wouldn't work in any browser I know of.

Garrett

 

[David Mark]

Event handler attributes on body causing an event handler being added to
window.

You are repeating yourself.

e.g. Detect `focus` event on arbitrary element, as supported in most
modern browsers.

Detecting focus on an arbitrary element does not add a property to
window.

Result: body onfocus attribute causes a focus event handler to be added
to window.

Of course it does, just like load/unload. So why would you conduct
such a test on the body?

I can't remember if removeAttribute caused the window's event
handler to be set to null, but it sounds risky to rely on anything from
that.

I don't know and yes.

There were other issues, but I can't finger them out of my brain ATM.

I think I've laid out the pattern as well as it is going to be laid
out. The rest is up to your brain (whenever it feels up to it).

 

[David Mark]

Having code lifted can seem frustrating -- don't blame me for that

My code wasn't lifted (the credit is quite clear), though I don't
particularly care for the spin put on the explanation.

and
don't whine.

You can't carry that off.

If the idea came from you then state so and make it clear
where the idea came from.

I wouldn't have to keep repeating it if - for example - you would stop
with the amnesia-induced comments.

http://groups.google.com/group/comp...3858ff6b0f/d216c4b1c2b3c7ec?#d216c4b1c2b3c7ec

Note what I said:-

| 1) Detect setAttribute works, if not check | property for null or
| function (IE)
| 2) Set an onclick attribute on a created
| element
| 3) Check onclick property for function

....and who I was responding to (you) and who wrote the very next
message in the thread (Kangax). The now-famous blog post, which spun
the explanation a little differently, referring to the salient bit as
a workaround for FF, followed a week or two later. It's not a
workaround for FF. It works for all but IE6/7 (and IE8 legacy modes,
just as I predicted in the very next message).

And the first thread that included the code was a full year before
that one:-

http://groups.google.com/group/comp...0878c7c67c/6641a9bce1e18d7d?#6641a9bce1e18d7d

Get the picture?

For more information on pitfalls of `isEventSupported` (i'm referring to
kangax' rendition), please see the comments on kangax github project
"isEventSupported".

The rendition is basically the same as mine. It's just written up on
a blog so that more people could find it. Apparently a github project
too. Whatever. I don't need to read any comments about it as I
invented it. Furthermore, now that I've reminded you that it is only
reliable for DOM0, you shouldn't need to read any more comments on it
either.

There were more comments in email discussion, as
well. Time permitting, I'll post.

Whatever. Time permitting, I'll read.

I've not caught up with your other replies, nor those of TPEL.

What other replies?

[...]

Oh screw that.  That's what people were trying to do until I came up
with the attribute reflection thing.

People were trying a proposal as if it had been implemented? That seems
very strange. It wouldn't work in any browser I know of.

As explained in Kangax' blog post, there were attempts to detect event
support by attaching listeners and dispatching events, but they proved
awkward and untenable. We went over that long ago as well.

 

[David Mark]

My code wasn't lifted (the credit is quite clear), though I don't
particularly care for the spin put on the explanation.

And if you meant ExtJS, I'm sure they thought they were lifting it
from Kangax. I don't see how you interpreted my response as blaming
you for somebody else lifting code from Kangax' blog without
attribution.