I played around with some basic benchmarks using firebug and couldn't
really save more than a couple milliseconds on a typical structure of
about 5 nested elements. I was able to save about 30 milliseconds on
40 nested elements. I think there are a few places to optimize the
current offset method but overall it is _just_ a slow and painful
process. There are usually other ways to structure the document where
getting the offset isn't necessary and that is usually the best
approach. The offset method can provide for quick prototyping and help
in those cases where lots of quick calls are not made a few
milliseconds for the typical implementation will not hurt it.
Getting the pixel values for non-pixel values is a whole different
story. That is something I know dojo is working on and I think Dean
has some stuff in his base library. However, last I checked progress
was limited and it is not pretty.
--
Brandon Aaron
On 12/8/06, Dave Methvin <[EMAIL PROTECTED]> wrote:
>
> >> Perhaps it just needs a bit of minor refactoring?
> >>
> >> Still keep offset, but simplify it to use other plugins (that you
> >> could use separately if you only wanted the left position of an
> >> element for instance):
> >>
> >> jQuery.fn.offset = function(refElem) {
> >> var elem = this[0];
> >> return {
> >> left: this.realLeft() - jQuery(refElem).realLeft(),
> >> top: this.realTop() - jQuery(refElem).realTop(), ....etc
> >> }
> >> }
> >
> > With an approach like this it would be even slower since it
> > would have to query the DOM all over again just to get the
> > left and then the top.
> > Perhaps separating out the scroll offsets into its own method
> > would be worth while. Getting the scroll offsets is very expensive
> > since it can't just rely on offsetParent.
>
> Requests for these properties definitely need to be "batched"; it's too
> expensive to make successive calls for the same element. Yesterday I was
> thinking the best approach was to just grab it all and return a single
> object with all the properties the way dimensions .offset() does now, but
> that could be wasteful when some of them are expensive and unneeded. Luke
> Lutman suggested passing an array into .attr() in the "How to get $.css"
> thread, that might be a tactic worth exploring because you could get just
> the stuff the user wanted but have the economy of doing the expensive
> operations once.
>
> The approach I proposed a while back was to first see if the standard style
> interfaces returned measures with "px"; if so use them. If not (mostly the
> IE case I think) use the jQuery.swap trick to zero out the stuff you're not
> interested in and measure what's left. That's the trick already used for
> height and width in .attr(). Margins are a bit tougher, it may be possible
> to find them by wrapping the measured element in a div and getting the
> clientWidth of the wrapper.
>
> At the time I desperately needed a solution the dimensions plugin wasn't
> around, and I haven't had the need for it since then so I haven't put it
> through any testing. It seems like the problem comes up frequently enough
> and a bulletproof solution is tough, so it definitely makes sense to have
> the plugin. This might even go in the core once it's all shaken out.
>
>
>
>
> _______________________________________________
> jQuery mailing list
> [email protected]
> http://jquery.com/discuss/
>
_______________________________________________
jQuery mailing list
[email protected]
http://jquery.com/discuss/
