John you should start with Sizzle then, where the basic build will be
something like:
function Sizzle(selector, context){
return Array.prototype.slice.call((context ||
document).quertySelectorAll(selector));
};
Makes sense for every Sizzle based library, famous or "home made" one, no?
Regards
On Sat, Aug 22, 2009 at 7:32 PM, John Resig <jere...@gmail.com> wrote:
>
> Additionally, if there is an appreciable difference, it's likely that
> we would just change the logic in jQuery itself to only initialize the
> specific code branches once (which is something that we should be
> doing anyway).
>
> --John
>
>
>
> On Sat, Aug 22, 2009 at 2:01 PM, Kevin Dalman<kevin.dal...@gmail.com>
> wrote:
> >
> > For this idea to be taken seriously, I think you would need to create
> > such a version and benchmark it VS the all-in-one jQuery.js. IF you
> > can show significantl performance differences, then perpahs your idea
> > could gain some traction (though I'm not in favor of it). But if we
> > are only talking about *a few milliseconds* difference in normal use,
> > then this would not justify the increased maintenance and code
> > required at every level - development, testing, documentation, library
> > linking, etc. IMO, the performance improvemetns would need to be
> > significant and *noticeable* to justify all this extra work and
> > complication. Making users add branching logic to every page is not a
> > small matter.
> >
> > My 2-cents.
> >
> > /Kevin
> >
> > On Aug 21, 4:01 am, ludovic <ludothebe...@gmail.com> wrote:
> >> @DBj
> >>
> >> Not exactly.
> >>
> >> Before use, we generate a few browser-specific jquery files, like
> >> jquery.ie7.js, jquery.ie6.js. Theses files are generated server-side
> >> from the current jquery.js file from a support detection database. For
> >> example, for IE6, we already know that the box model isn't supported.
> >> So we replace all occurrences of if( jQuery.support.boxModel )
> >> { instruction a } else { instruction b } by instruction b.
> >>
> >> We still have a jQuery file like we have currently. It can work on a
> >> generic browser as the feature detection is made dynamically. It is a
> >> bit slower as there are more conditions. The file name is jquery.js.
> >> This file is downloaded only if there is no browser-specific jquery
> >> file.
> >>
> >> Now, when the page is loading, we can have two policices :
> >> - One based on user agent : if it is a user agent corresponding to one
> >> of our precomputed files, we download the precomputed one, and not
> >> jquery.js. Else, we download the generic file, I mean jquery.js
> >>
> >> - Another one based on client-side detection, with for example
> >> <!--[if lt IE 7]>
> >> <!-- Internet Explorer before IE7 -->
> >> <script src="jquery.2.ie_before_7.js" ></script>
> >> <![endif]-->
> >>
> >> So, what I propose is what you called "the ultimate solution" and my
> >> precedent message explained how I would generate the different files.
> >>
> >> Regards,
> >> Ludovic
> > >
> >
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
