My vote goes to #1 and #2. Anyone else care to vote or discuss?
On Tue, 5 Jan 2010 18:18:25 -0500, Rick Waldron <waldron.r...@gmail.com> wrote: > I vote *YES *on all of these. > > > > > > On Tue, Jan 5, 2010 at 4:55 PM, webbiedave > <webbied...@websiteguard.com>wrote: > >> OK. Not sure where we're at on this but I'm hoping some sort of consensus >> can be achieved. Here are the approaches being bandied about to allow >> auto-detect of json (and perhaps other dataTypes): >> >> >> 1) Allow $.ajax() to accept multiple expected data types, i.e., >> dataTypes: >> ['json', 'html']. jQuery will attempt to auto-detect only those types. >> >> 2) New setting/option to have $.ajax() auto-detect/translate via response >> content-type. This will detect/translate any of the supported data types >> (and future data types) via the response Content-Type header. >> >> 3) Change dataType:null's auto-detect (intelligent guess) to include >> json. >> >> 4) New setting/option to have $.ajax() auto-detect html, xml and json. >> >> >> Be so kind as to re-vote in case these added details have changed your >> minds. >> >> >> >> >> >> On Tue, 29 Dec 2009 09:46:50 -0500, "Rick Waldron" >> <waldron.r...@gmail.com >> > >> wrote: >> > This is good. #2 has solid support. >> > >> > John, care to chime in this? >> > >> > >> > >> > -- Sent from my Palm Prē >> > Julian Aubourg wrote: >> > >> > So it was pure #2 obviously, not #1. >> > >> > 2009/12/29 Julian Aubourg <aubourg.jul...@gmail.com> >> > >> > Again, why not do this with an Accept header? >> > Client >> > sends acceptable content types, server responds with a content type, if >> > the server's response is one of the accepted types, jQuery processes >> > accordingly, if not, jQuery returns data unprocessed. >> > The dataType option should be for things that >> > aren't necessarily well communicated via content-type alone, like >> > JSONP, or anything else that modifies the nature of the request, not >> > just the content type. >> > If you're worried about your server sending >> > malicious javascript, then only accept text/plain or text/xml (even >> > dataType: 'html' isn't safe since it executes script blocks). If you >> > don't care, then accept "*/*". >> > >> > >> > >> > >> > There are a couple of reasons why an accept / content-type system is >> > not >> > that simple: >> > 1) When not specifying a dataType, accept is */* (which makes sense >> > since >> > we don't expect a particular dataType) while current behaviour is to >> > autodetect xml against text (or, maybe, in future extensions, to >> autodetect >> > any type). The only workaround if you're basing your tests around the >> > accept header would be to associate all of the xx/yy possibilities >> > known >> to >> > men with their corresponding dataType. The behaviour, as it is now, is >> > to >> > group correspondance from content-type to dataType using simple regexps >> (ie >> > /xml/, /json/) which I find much more efficient and not too >> > configuration >> > heavy. >> > >> > >> > 2) It still doesn't address the issue of specifying a set of accepted >> > dataTypes just with the dataType property (which is a much better >> > abstraction than setting content-type headers in a beforeSend callback >> > or >> > globally adding accepted types in ajaxSettings). >> > >> > >> > >> > I'm beginning to wonder if we're not buzzing for nothing with this >> > conversation. Actually, not specifying a dataType could very well >> > behave >> as >> > a guess-anything system. In analogy to what you said with content-type, >> > setting a dataType will prevent any automatic decision, so existing >> > code >> > that would be impacted by automatic json evaluation would just have to >> add >> > the dataType option, something I don't see as such an atrocious >> maintenance >> > task it would require some heavy-weight system in jQuery. >> > >> > >> > >> > So, the more I think about it, the more I'm in favor of #1. >> > >> > 2009/12/28 Erik Beeson <erik.bee...@gmail.com> >> > >> > >> > Again, why not do this with an Accept header? >> > Client sends acceptable content types, server responds with a content >> type, >> > if the server's response is one of the accepted types, jQuery processes >> > accordingly, if not, jQuery returns data unprocessed. >> > >> > >> > >> > The dataType option should be for things that aren't necessarily well >> > communicated via content-type alone, like JSONP, or anything else that >> > modifies the nature of the request, not just the content type. >> > >> > >> > >> > If you're worried about your server sending malicious javascript, then >> only >> > accept text/plain or text/xml (even dataType: 'html' isn't safe since >> > it >> > executes script blocks). If you don't care, then accept "*/*". >> > >> > >> > >> > Or am I missing something? >> > --Erik >> > >> > On Mon, Dec 28, 2009 at 12:51 PM, Rick Waldron <waldron.r...@gmail.com> >> > wrote: >> > >> > >> > >> > I can compromise with your #2, and give them both my vote. >> > >> > Passing it on... >> > >> > >> > >> > 1. Allow $.ajax() to accept multiple expected dataTypes. >> > >> > >> > >> > 2. Setting to have $.ajax() auto-detect/translate via response >> content-type >> > >> > header. >> > >> > >> > >> > >> > Julian - your thoughts? >> > >> > >> > On Mon, Dec 28, 2009 at 3:39 PM, webbiedave >> > <webbied...@websiteguard.com> wrote: >> > >> > >> > >> > >> > >> > Rick, your 1 (which I too have suggested in the past) might bring about >> > >> > unease as folks would prefer any eval-ing to come through explicit >> request. >> > >> > I also think it's imperative that the behavior of any dataType setting >> > >> > (including null) shouldn't change (especially to one that suddenly >> evals!). >> > >> > But that's just my opinion. My 1, 2 would be: >> > >> > >> > >> > 1. Allow $.ajax() to accept multiple expected dataTypes. >> > >> > >> > >> > 2. Setting to have $.ajax() auto-detect/translate via response >> content-type >> > >> > header. >> > >> > >> > >> > >> > >> > >> > >> > On Mon, 28 Dec 2009 15:03:22 -0500, Rick Waldron >> > <waldron.r...@gmail.com> >> > >> > wrote: >> > >> >>> >> > >> >>> We're struggling with the best way to inform .ajax() that we expect >> > >> >>> multiple data types. Either, with a setting like "auto" or by passing >> an >> > >> >>> array of data types (or maybe allowing both). >> > >> >>> >> > >> >> >> > >> >> Perhaps it would help if we defined a list of goals. I'll start. >> > >> >> >> > >> >> 1. $.ajax() - if dataType has not been defined in the argument list, >> > >> >> $.ajax() should respect the returned Content-type header and translate >> > >> >> accordingly. >> > >> >> >> > >> >> 2. .... >> > >> >> >> > >> >> >> > >> >> Fill it in! >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> Rick >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> On Sun, Dec 27, 2009 at 7:41 PM, <webbied...@websiteguard.com> wrote: >> > >> >> >> > >> >>> We're struggling with the best way to inform .ajax() that we expect >> > >> >>> multiple data types. Either, with a setting like "auto" or by passing >> an >> > >> >>> array of data types (or maybe allowing both). >> > >> >>> >> > >> >>> >> > >> >>> On Sun, 27 Dec 2009 12:02:54 -0800, Erik Beeson >> >>> <erik.bee...@gmail.com> >> > >> >>> wrote: >> > >> >>> > Seems like a lot of awkward wheel reinventing going on here. >> >>> > Content >> > >> >>> > type negotiation is a feature of HTTP; is there a reason we aren't >> > >> >>> > using it? >> > >> >>> > >> > >> >>> > --Erik >> > >> >>> > >> > >> >>> > >> > >> >>> > On Saturday, December 26, 2009, webbiedave >> > >> >>> > <webbied...@websiteguard.com> >> > >> >>> > wrote: >> > >> >>> >> "Following your idea that a library has to keep exactly the same >> > >> >>> >> behavior from versions to versions [...] then what happens if & >> >>> >> when >> > >> >>> >> jQuery introduces a new auto-detectable dataType in 1.4.1" >> > >> >>> >> >> > >> >>> >> Things could break *without* the introduction of new >> >>> >> auto-detectable >> > >> >>> >> types. If you use "auto" and are only handling json and html and >> > >> >>> >> suddenly javascript is returned, that javascript will be eval'd >> >>> >> and >> > >> >>> >> things will will not turn out well. That's why you can't use >> >>> >> "auto" >> > >> > on >> > >> >>> >> untrusted/incompetent servers. That's the whole point of "auto". >> >>> >> You >> > >> >>> >> are trusting the server to return the correct data. Use at your >> >>> >> own >> > >> >>> >> risk. But it's there if you need it. >> > >> >>> >> >> > >> >>> >> Having said that, #1 in my suggestions is passing an array >> (dataType: >> > >> >>> >> ["json", html"]). >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> On Dec 26, 6:41 pm, Julian Aubourg <aubourg.jul...@gmail.com> >> >>> >> wrote: >> > >> >>> >>> > As I mentioned in my previous >> > >> >>> >>> > post, one of this approach's downside is "null vs auto" >> >>> >>> > confusion >> > >> >>> >>> > as >> > >> >>> >>> > auto is like null plus more (json, script, future accepted >> > >> >>> dataTypes). >> > >> >>> >>> > The whole point is that "auto" means auto-detect type via >> > >> >>> content-type >> > >> >>> >>> > headers and null does not mean that (it means guess between >> >>> >>> > html >> > >> > or >> > >> >>> >>> > xml) >> > >> >>> >>> >> > >> >>> >>> This is exactly where the solution is inconsistent. >> > >> >>> >>> >> > >> >>> >>> "auto", in your implementation, does not mean "null plus more >> (json, >> > >> >>> >>> script, >> > >> >>> >>> *future accepted dataTypes*)" but it just means "null plus json >> >>> >>> & >> > >> >>> >>> script" >> > >> >>> >>> and only that. Following your idea that a library has to keep >> > >> > exactly >> > >> >>> >>> the >> > >> >>> >>> same behavior from versions to versions (which jQuery broke btw >> when >> > >> >>> >>> ditching the @ syntax for attributes in selectors) then what >> happens >> > >> >>> >>> if >> > >> >>> >>> & >> > >> >>> >>> when jQuery introduces a new auto-detectable dataType in 1.4.1? >> >>> >>> You >> > >> >>> >>> create >> > >> >>> >>> an "auto2" dataType so that existing code running in 1.4 is >> > >> >>> >>> unaffected >> > >> >>> >>> (ie: >> > >> >>> >>> the new dataType is not auto-detected)? How would you document >> >>> >>> such >> > >> > a >> > >> >>> >>> behaviour? What happens when there's another auto-detectable >> > >> > dataType >> > >> >>> >>> introduced in 1.4.2? >> > >> >>> >>> >> > >> >>> >>> Giving programmers a way to specify exactly the dataTypes they >> > >> > expect >> > >> >>> to >> > >> >>> >>> be >> > >> >>> >>> auto-detected is the way to go (would it be with an array or an >> > >> >>> >>> expression). >> > >> >>> >>> Just add a s.dataType = s.dataType || [text,xml] in the ajax code >> > >> > and >> > >> >>> >>> you're >> > >> >>> >>> done: no backward compatibility issue... plus you're safe for >> future >> > >> >>> >>> developments in the dataType auto-detection area. >> > >> >>> >>> >> > >> >>> >>> 2009/12/27 webbiedave <webbied...@websiteguard.com> >> > >> >>> >>> >> > >> >>> >>> > "Second, auto seems like the weirdest thing ever to me used >> >>> >>> > like >> > >> > it >> > >> >>> is >> > >> >>> >>> > here. So dataType==null and dataType=="auto" act the same for >> >>> >>> > xml >> > >> >>> >>> > but >> > >> >>> >>> > not for script & json? Seems completely inconsistant to me." >> > >> >>> >>> >> > >> >>> >>> > It's not that weird. I don't think that different settings >> > >> > yielding >> > >> >>> >>> > different results is necessarily inconsistent. There are two >> >>> >>> > ways >> > >> >>> >>> > to >> > >> >>> >>> > get xml and now there'll be a third. As I mentioned in my >> previous >> > >> >>> >>> > post, one of this approach's downside is "null vs auto" >> >>> >>> > confusion >> > >> >>> >>> > as >> > >> >>> >>> > auto is like null plus more (json, script, future accepted >> > >> >>> dataTypes). >> > >> >>> >>> > The whole point is that "auto" means auto-detect type via >> > >> >>> content-type >> > >> >>> >>> > headers and null does not mean that (it means guess between >> >>> >>> > html >> > >> > or >> > >> >>> >>> > xml). It is imperative that the behavior of dataType: null >> remains >> > >> >>> the >> > >> >>> >>> > same so this is a way to do that while affording multiple >> expected >> > >> >>> >>> > dataTypes in a way that's secure, doesn't bloat and doesn't >> >>> >>> > break >> > >> >>> >>> > existing apps. Quite frankly, it usage makes simple sense to me >> > >> > and >> > >> >>> >>> > those who need it will know exactly what it means and how to >> >>> >>> > use >> > >> > it >> > >> >>> >>> > (and will be relieved they can ditch their hacked libraries). >> > >> >>> >>> >> > >> >>> >>> > "If a coder does not want auto conversion, then he simply >> > >> > specifies >> > >> >>> >>> > a >> > >> >>> >>> > dataType (namely "text")." >> > >> >>> >>> >> > >> >>> >>> > But null does not mean auto convert. It means guess between >> >>> >>> > html >> > >> > or >> > >> >>> >>> > xml and that cannot change. >> > >> >>> >>> >> > >> >>> >>> > "But, please, do not introduce a behavior that will act >> > >> > differently >> > >> >>> >>> > for xml than it does for any other dataType deduced from >> >>> >>> > content >> > >> >>> >>> > type >> > >> >>> >>> > headers." >> > >> >>> >>> >> > >> >>> >>> > I admit I don't share your fear of such behavior and, in fact, >> > >> >>> greatly >> > >> >>> >>> > desire such a new setting. I'll know that my live apps that are >> > >> >>> >>> > using >> > >> >>> >>> > dataType: null will be unaffected and in the future I'd be able >> to >> > >> >>> >>> > write ajax calls that can respond to various data types. Also, >> > >> > I've >> > >> >>> >>> > suggested several approaches and look forward to reading what >> > >> >>> >>> > others >> > >> >>> >>> > think of them. >> > >> >>> >>> >> > >> >>> >>> > On Dec 26, 3:47 pm, Julian Aubourg <aubourg.jul...@gmail.com> >> > >> >>> >>> > wrote: >> > >> >>> >>> > > Regardless, I'm leaning towards the dataType: "auto" approach >> as >> > >> >>> >>> > > it's easy to use/implement and affords enough control. >> > >> >>> >>> >> > >> >>> >>> > > Well, so, first, I translated the dataType to "auto" when it >> was >> > >> >>> >>> > > null/undefined in my rewriting (because I hate >> >>> >>> > > messy/undefined >> > >> >>> >>> > > values). >> > >> >>> >>> > But >> > >> >>> >>> > > that's no biggy. >> > >> >>> >>> >> > >> >>> >>> > > Second, auto seems like the weirdest thing ever to me used >> >>> >>> > > like >> > >> >>> >>> > > it >> > >> >>> >>> > > is >> > >> >>> >>> > here. >> > >> >>> >>> > > So dataType==null and dataType=="auto" act the same for xml >> >>> >>> > > but >> > >> >>> >>> > > not >> > >> >>> >>> > > for >> > >> >>> >>> > > script & json? Seems completely inconsistant to me. >> > >> >>> >>> >> > >> >>> >>> > > If a coder does not want auto conversion, then he simply >> > >> >>> >>> > > specifies >> > >> >>> a >> > >> >>> >>> > > dataType (namely "text"). You just have to document it. But, >> > >> >>> please, >> > >> >>> >>> > > do >> > >> >>> >>> > not >> > >> >>> >>> > > introduce a behavior that will act differentely for xml than >> >>> >>> > > it >> > >> >>> does >> > >> >>> >>> > > for >> > >> >>> >>> > any >> > >> >>> >>> > > other dataType deduced from content type headers. >> > >> >>> >>> >> > >> >>> >>> > > 2009/12/26 webbiedave <webbied...@websiteguard.com> >> > >> >>> >>> >> > >> >>> >>> > > > I was referring solely to the "bitwise or" style. >> >>> >>> > > > Regardless, >> > >> >>> >>> > > > I'm >> > >> >>> >>> > > > leaning towards the dataType: "auto" approach as it's easy >> >>> >>> > > > to >> > >> >>> use/ >> > >> >>> >>> > > > implement and affords enough control. >> > >> >>> >>> >> > >> >>> >>> > > > Julian Aubourg wrote: >> > >> >>> >>> >> > >> >>> >>> > > > > As for string expressions not being in the calling style >> >>> >>> > > > > of >> > >> >>> >>> > > > > jQuery... >> > >> >>> >>> > > > > well... I really disagree here, since jQuery has >> >>> >>> > > > > expression >> > >> >>> >>> > > > > parsed >> > >> >>> >>> > parsed >> > >> >>> >>> > > > > pretty much everywhere ;) >> > >> >>> >>> >> > >> >>> >>> > > > -- >> > >> >>> >>> >> > >> >>> >>> > > > 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%2bunsubscr...@googlegroups.com<jquery-dev%252bunsubscr...@googlegroups.com> >> <jquery-dev%252bunsubscr...@googlegroups.com<jquery-dev%25252bunsubscr...@googlegroups.com> >> > >> > >> > >> > >> > >> > >> > >> >>> >> > >> > >> <jquery-dev%252bunsubscr...@googlegroups.com<jquery-dev%25252bunsubscr...@googlegroups.com> >> <jquery-dev%25252bunsubscr...@googlegroups.com<jquery-dev%2525252bunsubscr...@googlegroups.com> >> > >> > >> > >> > >> > >> > >> > >> >>> > >> > >> >>> >>> >> > >> >>> >>> > > > . >> > >> >>> >>> > > > For more options, visit this group at >> > >> >>> >>> > > >http://groups.google.com/group/jquery-dev?hl=en. >> > >> >>> >>> >> > >> >>> >>> > -- >> > >> >>> >>> >> > >> >>> >>> > 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<jquery-dev%2bunsubscr...@googlegroups.com> >> <jquery-dev%2bunsubscr...@googlegroups.com<jquery-dev%252bunsubscr...@googlegroups.com> >> > >> > >> > >> > >> > >> > >> > >> >>> >> > >> > >> <jquery-dev%2bunsubscr...@googlegroups.com<jquery-dev%252bunsubscr...@googlegroups.com> >> <jquery-dev%252bunsubscr...@googlegroups.com<jquery-dev%25252bunsubscr...@googlegroups.com> >> > >> > >> > >> > >> > >> > >> > >> >>> > >> > >> >>> >>> > . >> > >> >>> >>> > For more options, visit this group at >> > >> >>> >>> >http://groups.google.com/group/jquery-dev?hl=en. >> > >> >>> >> >> > >> >>> >> -- >> > >> >>> >> >> > >> >>> >> You received this message because you are subscribed to the Google >> > >> >>> Groups >> > >> >>> >> "jQuery Development" group. >> > >> >>> >> To post to this group, send email to jquery-...@googlegroups.com. >> > >> >>> >> To unsubscribe from this group, send email to >> > >> >>> >> >> > >> > >> jquery-dev+unsubscr...@googlegroups.com<jquery-dev%2bunsubscr...@googlegroups.com> >> <jquery-dev%2bunsubscr...@googlegroups.com<jquery-dev%252bunsubscr...@googlegroups.com> >> > >> > >> > >> > >> > >> > >> > >> >>> . >> > >> >>> >> For more options, visit this group at >> > >> >>> >> http://groups.google.com/group/jquery-dev?hl=en. >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> > >> > >> >>> > -- >> > >> >>> > >> > >> >>> > You received this message because you are subscribed to the Google >> > >> >>> > Groups >> > >> >>> > "jQuery Development" group. >> > >> >>> > To post to this group, send email to jquery-...@googlegroups.com. >> > >> >>> > To unsubscribe from this group, send email to >> > >> >>> > >> > >> > >> jquery-dev+unsubscr...@googlegroups.com<jquery-dev%2bunsubscr...@googlegroups.com> >> <jquery-dev%2bunsubscr...@googlegroups.com<jquery-dev%252bunsubscr...@googlegroups.com> >> > >> > >> > >> > >> > >> > >> > >> >>> . >> > >> >>> > For more options, visit this group at >> > >> >>> > http://groups.google.com/group/jquery-dev?hl=en. >> > >> >>> >> > >> >>> -- >> > >> >>> >> > >> >>> You received this message because you are subscribed to the Google >> > >> > Groups >> > >> >>> "jQuery Development" group. >> > >> >>> To post to this group, send email to jquery-...@googlegroups.com. >> > >> >>> To unsubscribe from this group, send email to >> > >> >>> >> > >> > >> jquery-dev+unsubscr...@googlegroups.com<jquery-dev%2bunsubscr...@googlegroups.com> >> <jquery-dev%2bunsubscr...@googlegroups.com<jquery-dev%252bunsubscr...@googlegroups.com> >> > >> > >> > >> > >> > >> > >> > >> >>> . >> > >> >>> For more options, visit this group at >> > >> >>> http://groups.google.com/group/jquery-dev?hl=en. >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >> >> > >> >> -- >> > >> >> >> > >> >> You received this message because you are subscribed to the Google >> Groups >> > >> >> "jQuery Development" group. >> > >> >> To post to this group, send email to jquery-...@googlegroups.com. >> > >> >> To unsubscribe from this group, send email to >> > >> >> jquery-dev+unsubscr...@googlegroups.com<jquery-dev%2bunsubscr...@googlegroups.com> >> . >> > >> >> For more options, visit this group at >> > >> >> http://groups.google.com/group/jquery-dev?hl=en. >> > >> > >> > >> > -- >> > >> > >> > >> > You received this message because you are subscribed to the Google >> > Groups >> > "jQuery Development" group. >> > >> > To post to this group, send email to jquery-...@googlegroups.com. >> > >> > To unsubscribe from this group, send email to >> > jquery-dev+unsubscr...@googlegroups.com<jquery-dev%2bunsubscr...@googlegroups.com> >> . >> > >> > For more options, visit this group at >> > http://groups.google.com/group/jquery-dev?hl=en. >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > -- >> > >> > You received this message because you are subscribed to the Google >> > Groups >> > "jQuery Development" group. >> > >> > >> > To post to this group, send email to jquery-...@googlegroups.com. >> > >> > >> > To unsubscribe from this group, send email to >> > jquery-dev+unsubscr...@googlegroups.com<jquery-dev%2bunsubscr...@googlegroups.com> >> . >> > >> > >> > For more options, visit this group at >> > http://groups.google.com/group/jquery-dev?hl=en. >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > -- >> > >> > You received this message because you are subscribed to the Google >> > Groups >> > "jQuery Development" group. >> > >> > >> > To post to this group, send email to jquery-...@googlegroups.com. >> > >> > >> > To unsubscribe from this group, send email to >> > jquery-dev+unsubscr...@googlegroups.com<jquery-dev%2bunsubscr...@googlegroups.com> >> . >> > >> > >> > For more options, visit this group at >> > http://groups.google.com/group/jquery-dev?hl=en. >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > -- >> > >> > You received this message because you are subscribed to the Google >> > Groups >> > "jQuery Development" group. >> > >> > >> > To post to this group, send email to jquery-...@googlegroups.com. >> > >> > >> > To unsubscribe from this group, send email to >> > jquery-dev+unsubscr...@googlegroups.com<jquery-dev%2bunsubscr...@googlegroups.com> >> . >> > >> > >> > For more options, visit this group at >> > http://groups.google.com/group/jquery-dev?hl=en. >> > >> > >> > >> > -- >> > >> > You received this message because you are subscribed to the Google >> > Groups >> > "jQuery Development" group. >> > To post to this group, send email to jquery-...@googlegroups.com. >> > To unsubscribe from this group, send email to >> > jquery-dev+unsubscr...@googlegroups.com<jquery-dev%2bunsubscr...@googlegroups.com> >> . >> > For more options, visit this group at >> > http://groups.google.com/group/jquery-dev?hl=en. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "jQuery Development" group. >> To post to this group, send email to jquery-...@googlegroups.com. >> To unsubscribe from this group, send email to >> jquery-dev+unsubscr...@googlegroups.com<jquery-dev%2bunsubscr...@googlegroups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/jquery-dev?hl=en. >> >> >> >>
-- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-...@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.
