Mousewheel event does not support DOM0 in FF [JavaScript]

Prev: really dumb error but it's stumped me
Next: FAQ Topic - What is a host object? (2010-06-03)

From: David Mark on 2 Jun 2010 18:46

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.

From: Garrett Smith on 2 Jun 2010 22:55

On 6/2/2010 3:46 PM, David Mark wrote:
> 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

From: David Mark on 3 Jun 2010 02:15

On Jun 2, 10:55 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
> On 6/2/2010 3:46 PM, David Mark wrote:
>
> > 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,

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. :)

From: David Mark on 3 Jun 2010 02:31

From: David Mark on 3 Jun 2010 04:34

On Jun 3, 2:15 am, David Mark <dmark.cins...(a)gmail.com> wrote:
> On Jun 2, 10:55 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
>
> > On 6/2/2010 3:46 PM, David Mark wrote:
>
> > > 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,
>
> 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.

>
> > 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
>

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

| Next | Last
Pages: 1 2
Prev: really dumb error but it's stumped me
Next: FAQ Topic - What is a host object? (2010-06-03)