Thanks for the quick replies, guys, I'll check out the fix ASAP. I'm assuming then that the new offset() covers for all supported browsers, and returns correct offset even with borders, margin, padding, etc.? jQuery.extend(true, "Awesome", "uber") !
Charles On Sep 12, 3:13 pm, "Brandon Aaron" <[EMAIL PROTECTED]> wrote: > In the transition of moving the new offset method into the core some bugs > showed up. I've addressed these issues in the latest SVN of jQuery and they > will be included in the upcoming jQuery 1.2.1. If you wouldn't mind grabbing > the latest code from SVN and seeing if that works for your site, that would > be great! > > Note that the new offset method does not have any options and any relative > offsets will need to be calculated manually. The upcoming new dimensions > plugin (currently in SVN) no longer has an offset or offsetLite method. It > still has offsetParent and position though. > > -- > Brandon Aaron > > On 9/12/07, polyrhythmic <[EMAIL PROTECTED]> wrote: > > > > > I would like to report also a 100% no-conflict upgrade to 1.2! Thanks > > for the hard work and the quick output. > > > That being said, I can't get offset() to work like expected. I use > > Dimensions offset() on my site in a tricky situation involving floats, > > padding, margin, etc. I tried to switch into offset() from the 1.2 > > core and I can't get it to work as expected, and I can't seem to > > pinpoint where it is failing. I tried to alter it slightly to pass it > > a different parentNode (as in Dimensions { relativeTo: element }) but > > the left: was still wrong. I also get different results from FF > > 2.0.0.6, IE6, and Opera 9.20. > > > Can you describe how the core offset() method works compared to the > > Dimensions offset() method? I know from the source the Dimensions > > offset() takes into account many different special cases, and > > offsetLite seems closer to core offset(), but not the same. I would > > like to add the info into the Wiki so coders will know when to use > > Dimensions and when core offset() is enough. > > > When I get home from work I'll try to get an example up, right now the > > site is back to Dimensions until I figure this out. > > > Charles > > doublerebel.com > > > On Sep 12, 8:58 am, "Web Specialist" <[EMAIL PROTECTED]> > > wrote: > > > Jörn, > > > > I know your great job in form validation plugin. Form Validation Plugin > > is > > > awesome. Period! > > > > I'll waiting that improvements looking for better performance. > > > > Thanks! > > > > 2007/9/12, Jörn Zaefferer <[EMAIL PROTECTED]>: > > > > > Bernd Matzner schrieb: > > > > > >> I'm using Jorn's Form Validation in a monster form. Using jQuery > > > > >> 1.2minified version returns all validation in =~ 16 sec. Using > > > > >> uncompressed > > > > >> version returns in 6 sec. > > > > > > Hi, somewhat unrelated to the thread: 6 or even 16 secs seem like an > > > > > eternity. What would be the disadvantages of using server-side > > > > > validation in such a case? I'm asking this because I keep wondering > > if > > > > > server-side validation is necessary anyway for non-JS visitors, why > > > > > not use Ajax and do the validation on the server and simply display > > > > > the errors using JS if available... > > > > > Please note that I never even tried to optimize the validation plugin > > > > for performance. I never had to deal with "monster forms", and still > > > > consider them problematic anyway. But it seems like there are quite a > > > > few people who have to deal with those monster forms, once I've got a > > > > testcase setup it should be possible to improve the performance a lot. > > I > > > > just have to find the actual bottleneck. > > > > > I guess serializing a monster form and sending it via ajax and then > > > > displaying messages via JS won't be that much faster. > > > > > -- Jörn