Hi Matt, Thanks for the reply. ... Good point. Well said. This logic is unfortunately used in YUI event.js. If the browser is detected to be Safari then click
Sep 4, 2006
1 of 5
Thanks for the reply.
On 9/4/06, Matt Warden <mwarden@...> wrote:
> On 9/4/06, Peter Michaux <petermichaux@...> wrote:
> > if (!el.addEventListener && !el.attachEvent)
> > with the fact that these very same browsers don't have call() anyway.
> > If the three uses of .call() were changed to .apply() then there would
> > be a little bit of consistency.
> Admittedly I do not fully understand what you're saying here, but I
> did want to point out that I don't think the check for
> addEventListener and attachEvent is a browser sniff. Making
> assumptions like "if A is not supported, this is Browser X, and
> therefore B is also not supported" is something developers have
> frowned upon for a good while now, favoring a strict method/function
> detection approach (e.g. "if A is not supported, then we don't use A.
> Separately, we check if B is supported before using B").
Good point. Well said. This logic is unfortunately used in YUI
event.js. If the browser is detected to be Safari then click and
dblclick events will use legacy events. However, I tested and it seems
that Safari 2 handles these events just fine with DOM2 events. So if
the library's use of legacy events handle click and dblclick without
any compromise in Safari 1.3 and 2.0, then why not just use legacy
events for click and dblclick in all browsers and eliminate the
browser sniff? If there is compromise what is it and can it be added
to the documentation?
> In light of this, would you instead suggest that we perform a
> detection on Function.call, or are you simply saying that
> Function.apply provides the same functionality (as used here) with
> broader support?
I am saying Function.apply() provides the same functionality with
All the rambling was just trying to show that the event library seems
to be trying to support the older browsers without Function.call() to
a certain degree but that using Function.call() was the limiting
factor. Switching to Function.apply() lets other parts of the library
be the limiting factors for even older browsers.
Staying with Function.call() isn't a bad idea either. Since
Function.call() is essential to the library there is no need to define
YAHOO.util.Event if Function.call() doesn't exist.
I suppose not much of this really matters in the reai world. I was
simply analyzing the library to see how far back the library would
I personally am going to stay with Function.call() in my trimmed
version of YUI! event.js and let the browser error if the browser
doesn't have it. I'm comfortable with this since Function.call() is a
I have also removed all of the legacy event stuff and changed the
getPageX methods. To accomodate Safari <=1.3, I simply won't use
dblclick events or try to preventDefault for single clicks on links in
DOM2 event handlers. With these changes and limits I have removed all
browser sniffing (ie navigator.userAgent). Also this cuts the library
from >8KB to ~3.5KB. Hopefully less code equals less maintaince and
none of these changes limit my needs.
Your message has been successfully submitted and would be delivered to recipients shortly.
Changes have not been saved
Press OK to abandon changes or Cancel to continue editing
Your browser is not supported
Kindly note that Groups does not support 7.0 or earlier versions of Internet Explorer.
We recommend upgrading to the latest Internet Explorer, Google Chrome, or Firefox. If you are using IE 9 or later, make sure you turn off Compatibility View.