From: Garrett Smith on
On 6/2/2010 11:31 PM, David Mark 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, 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
From: Garrett Smith on
On 6/2/2010 11:15 PM, David Mark 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.
>
>> 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
From: David Mark on
On Jun 3, 3:50 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
> On 6/2/2010 11:31 PM, David Mark 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, 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).

From: David Mark on
On Jun 3, 7:58 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
> On 6/2/2010 11:15 PM, David Mark 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.
>
> >> 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.lang.javascript/browse_thread/thread/2a26333858ff6b0f/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.lang.javascript/browse_thread/thread/b9812e0878c7c67c/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.
From: David Mark on
On Jun 3, 9:16 pm, David Mark <dmark.cins...(a)gmail.com> wrote:
> On Jun 3, 7:58 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
>
>
>
>
>
> > On 6/2/2010 11:15 PM, David Mark 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.
>
> > >> 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.