Mousewheel event does not support DOM0 in FF

Discussion in 'Javascript' started by David Mark, Jun 2, 2010.

  1. David Mark

    David Mark Guest

    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.
    David Mark, Jun 2, 2010
    #1
    1. Advertising

  2. 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
    Garrett Smith, Jun 3, 2010
    #2
    1. Advertising

  3. David Mark

    David Mark Guest

    On Jun 2, 10:55 pm, Garrett Smith <> 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. :)
    David Mark, Jun 3, 2010
    #3
  4. David Mark

    David Mark Guest

    On Jun 2, 10:55 pm, Garrett Smith <> 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?)
    David Mark, Jun 3, 2010
    #4
  5. David Mark

    David Mark Guest

    On Jun 3, 2:15 am, David Mark <> wrote:
    > On Jun 2, 10:55 pm, Garrett Smith <> 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
    David Mark, Jun 3, 2010
    #5
  6. On 6/2/2010 11:31 PM, David Mark wrote:
    > On Jun 2, 10:55 pm, Garrett Smith<> 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
    Garrett Smith, Jun 3, 2010
    #6
  7. On 6/2/2010 11:15 PM, David Mark wrote:
    > On Jun 2, 10:55 pm, Garrett Smith<> 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
    Garrett Smith, Jun 4, 2010
    #7
  8. David Mark

    David Mark Guest

    On Jun 3, 3:50 pm, Garrett Smith <> wrote:
    > On 6/2/2010 11:31 PM, David Mark wrote:
    >
    >
    >
    >
    >
    > > On Jun 2, 10:55 pm, Garrett Smith<>  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).
    David Mark, Jun 4, 2010
    #8
  9. David Mark

    David Mark Guest

    On Jun 3, 7:58 pm, Garrett Smith <> wrote:
    > On 6/2/2010 11:15 PM, David Mark wrote:
    >
    >
    >
    >
    >
    > > On Jun 2, 10:55 pm, Garrett Smith<>  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...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?

    > [...]
    >
    >
    >
    >
    >
    > >> 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.
    David Mark, Jun 4, 2010
    #9
  10. David Mark

    David Mark Guest

    On Jun 3, 9:16 pm, David Mark <> wrote:
    > On Jun 3, 7:58 pm, Garrett Smith <> wrote:
    >
    >
    >
    >
    >
    > > On 6/2/2010 11:15 PM, David Mark wrote:

    >
    > > > On Jun 2, 10:55 pm, Garrett Smith<>  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.
    David Mark, Jun 4, 2010
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ramon

    Need a faster MouseWheel

    Ramon, Dec 30, 2004, in forum: Java
    Replies:
    0
    Views:
    358
    Ramon
    Dec 30, 2004
  2. Nicholas Shewmaker

    How do I bind <MouseWheel> to scrollbar?

    Nicholas Shewmaker, Dec 14, 2005, in forum: Python
    Replies:
    1
    Views:
    504
    James Stroud
    Dec 15, 2005
  3. WaterWalk
    Replies:
    0
    Views:
    696
    WaterWalk
    Mar 1, 2007
  4. Richard Holmes

    Tk MouseWheel Support

    Richard Holmes, Mar 10, 2011, in forum: Python
    Replies:
    11
    Views:
    1,952
    Terry Reedy
    Mar 2, 2013
  5. Peter Michaux

    Feature testing DOM0 event interface

    Peter Michaux, Feb 12, 2008, in forum: Javascript
    Replies:
    23
    Views:
    309
    Thomas 'PointedEars' Lahn
    Feb 17, 2008
Loading...

Share This Page