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

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

Expand Messages
  • Matt Warden
    ... 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
    Message 1 of 5 , Sep 4, 2006
      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").

      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?

      --
      Matt Warden
      Cleveland, OH, USA
      http://mattwarden.com


      This email proudly and graciously contributes to entropy.
    • 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 2 of 5 , Sep 4, 2006
        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.