Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Mousewheel event does not support DOM0 in FF

Reply
Thread Tools

Mousewheel event does not support DOM0 in FF

 
 
David Mark
Guest
Posts: n/a
 
      06-02-2010
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.
 
Reply With Quote
 
 
 
 
Garrett Smith
Guest
Posts: n/a
 
      06-03-2010
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
 
Reply With Quote
 
 
 
 
David Mark
Guest
Posts: n/a
 
      06-03-2010
On Jun 2, 10:55*pm, Garrett Smith <(E-Mail Removed)> 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.
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      06-03-2010
On Jun 2, 10:55*pm, Garrett Smith <(E-Mail Removed)> 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, 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?)
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      06-03-2010
On Jun 3, 2:15*am, David Mark <(E-Mail Removed)> wrote:
> On Jun 2, 10:55*pm, Garrett Smith <(E-Mail Removed)> 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 bigdeal
> > > 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
 
Reply With Quote
 
Garrett Smith
Guest
Posts: n/a
 
      06-03-2010
On 6/2/2010 11:31 PM, David Mark wrote:
> On Jun 2, 10:55 pm, Garrett Smith<(E-Mail Removed)> 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, 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?)


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
 
Reply With Quote
 
Garrett Smith
Guest
Posts: n/a
 
      06-03-2010
On 6/2/2010 11:15 PM, David Mark wrote:
> On Jun 2, 10:55 pm, Garrett Smith<(E-Mail Removed)> 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
>


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.

[...]

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


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
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      06-04-2010
On Jun 3, 3:50*pm, Garrett Smith <(E-Mail Removed)> wrote:
> On 6/2/2010 11:31 PM, David Mark wrote:
>
>
>
>
>
> > On Jun 2, 10:55 pm, Garrett Smith<(E-Mail Removed)> *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 bigdeal
> >>> 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.

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


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

 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      06-04-2010
On Jun 3, 7:58*pm, Garrett Smith <(E-Mail Removed)> wrote:
> On 6/2/2010 11:15 PM, David Mark wrote:
>
>
>
>
>
> > On Jun 2, 10:55 pm, Garrett Smith<(E-Mail Removed)> *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 bigdeal
> >>> 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

>
> 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....16c4b1c2b3c7ec

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....41a9bce1e18d7d

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?

> [...]
>
>
>
>
>
> >> 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.

>
> 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.
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      06-04-2010
On Jun 3, 9:16*pm, David Mark <(E-Mail Removed)> wrote:
> On Jun 3, 7:58*pm, Garrett Smith <(E-Mail Removed)> wrote:
>
>
>
>
>
> > On 6/2/2010 11:15 PM, David Mark wrote:

>
> > > On Jun 2, 10:55 pm, Garrett Smith<(E-Mail Removed)> *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

>
> > 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 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Tk MouseWheel Support Richard Holmes Python 11 03-02-2013 11:14 PM
Feature testing DOM0 event interface Peter Michaux Javascript 23 02-17-2008 02:22 PM
Make Tkinter canvas respond to MouseWheel event WaterWalk Python 0 03-01-2007 02:08 AM
How do I bind <MouseWheel> to scrollbar? Nicholas Shewmaker Python 1 12-15-2005 05:18 AM
Need a faster MouseWheel Ramon Java 0 12-30-2004 01:57 AM



Advertisments