@DBJ Only based on browser headers won't always work! You will need a sniffing script that will do the feature detection and report back to the server, this way most feature detection will be done once (per session). An additional advantage of the PHP script will be the cache control, set for a distant expiration date and all other trick headers and won't have to reload. You can optionally also set a cookie with the script that stores these features, all cookies are still browser specific so there should be no problem there. Another nice option is you can always enable Gzip support from PHP, so jQuery will always be served as small as possible.
But instead of the dozens of small files I would prefer the big commented jQuery (the developer version), you could let the PHP script parse that live... it will be much nicer to have a single PHP and a single JS file. Besides, when you have commented the big developer version you can also generate these small files as needed. But instead of only thinking about backwards compatibility with ancient browsers we have to plan for forward compatibility. In the long run the browser market is going to change in a big way. It is conceivable that jQuery will soon also run on completely new browsers, and even totally different devices like those new TV's with embedded browsers and all kinds of mobile devices. With these new browsers the script and quirks will be a whole new level of pain to maintain, so *maintainability *is key. So i'd say the final word is with the jQuery developers on this. THD On Thu, Sep 3, 2009 at 6:26 PM, DBJDBJ <dbj...@gmail.com> wrote: > > @THD, Ludovic, Andrea > > Very usefull discusion, indeed. Although I would be so bold to *try* > this way : > > <script src="http://your.server.here.com/jquery_compositor.php"; ></ > script> > > Where on the server there are a lot of simple js files , one for each > feature in each browser. > No home-grown conditional comments etc ... > These files are used to actually build on-the-fly jQuery, for the > calling browser+platform combination. > > What bothers me is the number of these jQ nuggets (smal js files) for > each feature? > > Is the formula for their *max* number : (no of features) X (no of > browsers) X (no of OS's) ? > > There will be fortunately a lot of these "nuggets" reuse. For example. > > in_array.js --- for every browser on every OS , which is NOT IE > > ie_in_array.js --- for every IE browser > > I am sure you guys do need need more explaining ;o) > > --DBJ > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
