Loading ...
Sorry, an error occurred while loading the content.

Re: [ydn-javascript] Event.fireLegacyEvent() uses Function.call()?

Expand Messages
  • Peter Michaux
    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
    Message 1 of 5 , Sep 4 1:07 PM
    • 0 Attachment
      Hi Matt,

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

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

      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
      core JavaScript function and not specifically a client-side function.
      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.

      Peter
    Your message has been successfully submitted and would be delivered to recipients shortly.