jQuery Forum

Hey John,
this is a great resource you've found - I agree that we need to do
something.
As start, I would like to propose to run each test suites against ours
and APE:
1. http://dhtmlkitchen.com/ape/test/tests/dom/position-f-test.html
with jQuery's offset
2. ours with APE's offset
It seems there are still cases we haven't thought of - we first have
to fix the issues.

for( ; parent && parent !== container; parent = parent.parentNode) {
I didn't know this is valid syntax (everyone else knew this works?) -
interesting.
Their getOffsetCoords is a amazing piece of work - definitely worth
being investigated.

Yep, that's absolutely valid (just a tweaked for loop). We can
probably take new things in to consideration but we need to be careful
about copying code as their license is incompatible with ours.
But, yes, we need to make sure that we integrate the tests of their
test suite into ours, so we're shooting for full compatibility.
--John

> for( ; parent && parent !== container; parent = parent.parentNode) {
>
> I didn't know this is valid syntax (everyone else knew this
> works?) - interesting.
I think you knew it, but you didn't know that you knew it. :-)
The three expressions in a for loop are all optional. You can even leave out
all three, which is the classical way of writing an infinite loop in C-like
languages:
for(;;) { /* loop forever */ }
-Mike

Indeed, I knew you could do it in a couple of other languages,
but I've never seen a JavaScript contruct with optional syntax :)
Anyway, since the UI bugtracker is down, I'll be working on the
offset stuff a bit now :)

Guys,
after first testing rounds, I have some results to share:
- We don't pass APE's test suite (mostly fails add body positioning,
relative positions at this point I think)
- APE completely passes our test suite
- Using APE's offset method, UI sortables' time to call offset
decreases by about 900% - this is a true 900% performance increase (in
FF3!).
- During page initialization, APE is building up a lot of useful
constants - however, some of them are a bit tricky - they involve
setting various css on the body and appending test elements, later
resetting everything using the original cssText.

Interesting stuff! Definitely remember, though, that APEs license is
incompatible with ours, so you need to be sure that any code you
include in jQuery is original.
--John

I think it is great to see another library take the offset method to new levels. :)  I'll try to take a more detailed look at the comparison soon and see what I can do to raise the bar again.
--
Brandon Aaron

Just created a new branch called "offset_enhancements" to play around with some ideas I've got.
I just looked over the APE source ... WOW ... 20k uncompressed just for the position file ... our offset file is 6k uncompressed. As usual I'm sure we can find a nice balance of performance/size.
--
Brandon Aaron

Indeed!
Eduardo is working on a optimized version right now as a task
for Liferay. Will update you with the first results as soon as I got
something.

Didn't see your messages, only after posting :)
Brandon, it would be excellent if you could contact Eduardo
(eduardolundgren@gmail.com he's on GTalk as well),
so you can check out what he already did / work together.
Thanks,
Paul

On Jul 8, 7:03 pm, "Brandon Aaron" <brandon.aa...@gmail.com> wrote:
> Just created a new branch called "offset_enhancements" to play around with
> some ideas I've got.
>
> I just looked over the APE source ... WOW ... 20k uncompressed just for the
> position file ... our offset file is 6k uncompressed. As usual I'm sure we
> can find a nice balance of performance/size.
>
Comments and long variable names help keep complicated code less
confusing.
The comments alone are probably about 30% of the file size. Then
there's variables like:
IS_STATIC_BODY_OFFSET_PARENT_BUT_ABSOLUTE_CHILD_SUBTRACTS_BODY_BORDER_WIDTH
When minified, the file size changes drastically
position-f-min.js 3.6 kb
position-f.js 20.2 kb
(actual size, before gzip)
It will fail in Safari 2.0.4 in many cases. Safari 2 had an
implementation of offsetTop that was buggy in its own way, but in some
ways more closely matched that of MSIE, at some point, Safari changed
to a behavior much more in line with the CSSOM Views. CSSOM Views
defines an offsetTop that is (or was) different from what MSIE does
(MSIE8 seems to have changed). Safari 3 is closer to CSSOM Views (but
not exactly). The browser market has now about 8 different versions of
"offsetTop". All of the browsers are considerably different. This
advent makes finding an element's position (particularly cross
browser) extremely difficult.
I posted an idea for a new "displacedTop" property on the www-style
list. The idea was to not put any browser in an unfair position, not
break any existing sites, and have a clear definition of what the
property will return. The idea got some positive acknowledgment, but
didn't make way into any spec.
As for the for(;;) loop syntax, yes, it is perfectly valid and works
in all browsers except Mac IE 5 (IIRC).
> --
> Brandon Aaron
>
> On Tue, Jul 8, 2008 at 8:29 PM, Brandon Aaron <brandon.aa...@gmail.com>
>

On Fri, Jul 11, 2008 at 12:57 PM, <a href="mailto:dhtmlkitchen@gmail.com">dhtmlkitchen@gmail.com</a> <<a href="mailto:dhtmlkitchen@gmail.com">dhtmlkitchen@gmail.com</a>> wrote:

I got a LOT of reports from the "scrollTo family" set of plugins about
not scrolling well to absolute positioned elements (or elements inside
them, I'm not sure).
.offset() is used to get the position so this is probably the problem.
Just mentioning so you have it in mind. I'll try to find a test case
from my plugins.
Cheers
--
Ariel Flesler
http://flesler.blogspot.com/