Position reporting function: Flanagan, Yahoo!, Kruze, Prototype ... all broken at least a little.

[petermichaux]

Hi,

It seems like determining element position in a web page is a difficult
task. In the position reporting source code I've looked at there are
special fixes for at least some versions of Safari and Opera. I am
doing a lot of dragdrop experimentation and in some situations need a
position reporting function. The function doesn't need to report the
positions of exotic elements like images in button elements; however, I
would like a position reporting function that can at least handle
combinations of scrollable elements and tables.

I've been testing these libraries

* David Flanagan's JavaScript 5th ed, p362
* Yahoo! UI v0.11.3
* Matt Kruze's current Object Position library
* Prototype.js v1.5.0_rc1

with the two examples in this page

<URL: http://peter.michaux.ca/temp/position/scale.html>

in the following mainstream browsers

OS X 10.4
* Safari 2
* Opera 9
* Firefox 1.5

Win 98
* IE 6
* IE 5.5

All of the position reporting functions break in at least one of my
test examples.

I don't understand the 2px IE weirdness in the test results. Any ideas?

Does anyone know which versions of Opera and Safari required special
attention? Does anyone have position reporting code that doesn't
browser sniff and also works in these versions of Opera and Safari?

Given the influence this group has (or should have) on JavaScript
practices, I think it incredibly beneficial if the group could offer
the world a position reporting function that works at least up to a
listed set of medium difficulty cases.

Thank you,
Peter

 

[Matt Kruse]

It seems like determining element position in a web page is a
difficult task.

Indeed. Or at least, doing it in such a generalized way so as to work
correctly in any context.

* Matt Kruze's current Object Position library

s/z/s/

<URL: http://peter.michaux.ca/temp/position/scale.html>
OS X 10.4
* Safari 2
* Opera 9
* Firefox 1.5

I do not have a mac to test with. What are the results?

Win 98
* IE 6
* IE 5.5

Similarly, I don't test with Win98. What are the results?

Does anyone know which versions of Opera and Safari required special
attention? Does anyone have position reporting code that doesn't
browser sniff and also works in these versions of Opera and Safari?

Doubtful. Quirks that are specific to browser versions and/or OS are
difficult or impossible to feature-detect. That I know of.

Given the influence this group has (or should have) on JavaScript
practices, I think it incredibly beneficial if the group could offer
the world a position reporting function that works at least up to a
listed set of medium difficulty cases.

I believe my library does, as it seems the others do also. Maybe your test
case is sufficiently complex or your test browsers are sufficiently
broken/quirky.

People like Richard Cornford, who may actually have the experience and
knowledge necessary to solve the quirks you are experiencing, object to the
entire idea of writing a general-purpose position-finding function. And in
cases where he finds a flaw in existing code (like mine) he is cryptic about
the problem and reluctant to give advice. He's just one example - there are
other people who could offer support in writing such a function also, but
object to the very concept of writing such a function.

I've always been in favor of the experts of this group pooling their
knowledge and resources into writing solid, bullet-proof low-level functions
for very basic tasks that work across as many browsers and situations as
possible. There seems to be little interest.

At the very least, libraries like my Object Position and others improve on
the very flawed approach of just walking up the offsetParent chain and
adding up the offset values. That's the typical approach shown on sites like
Quirksmode, and wouldn't even come close to giving you the correct answers
in your test case!

If you find the solution to your problem or if anyone else can offer advice
on how to improve my code to handle more browser quirks and specific
situations, I would of course love to hear it.

 

[petermichaux]

Hi Matt,

Indeed. Or at least, doing it in such a generalized way so as to work
correctly in any context.

I'm not really interested in *any* context. Surely the more complicated
cases would bloat the code severly. However the mild to medium cases
which are common should be containable in a relative small function.

s/z/s/


I do not have a mac to test with. What are the results?

I believe that the only error I found with your library was in Opera 9

"bluebox should be (100,100) and Kruze says is (150,150)"

I would like to know the results in Opera 8 or 7 or which ever Opera
you were using when you wrote the code. Perhaps the browser sniffing
worked then but broke when Opera 9 fixed a bug?

Similarly, I don't test with Win98. What are the results?

Sorry I meant Windows XP.

Doubtful. Quirks that are specific to browser versions and/or OS are
difficult or impossible to feature-detect. That I know of.

Richard Cornford made a suggestion to me in another post that might
give a clue to a last resort type of solution.

<URL:
http://groups.google.com/group/comp.lang.javascript/msg/312ff8d4ea3cb11b>

The idea of creating an element onload and then manipulating and
analyzing it to see the resulting browser behavior is a very
interesting and creative approach. It seems laborious but *if* nothing
else works and this approach will not break as time passes then it
sounds very good to me.

Even if I am way off in suggesting this solution might work in this
case it shows how creatively and cleverly the JavaScript code can be
written. I have been impressed with other sneaky tips suggested here to
avoid browser sniffing.

I believe my library does, as it seems the others do also. Maybe your test
case is sufficiently complex or your test browsers are sufficiently
broken/quirky.

My test cases were relatively simple: scrolling divs and a table. If
your code can be adjusted to handle this in Opera 9 then perhaps it
does. But the browser sniffing is what makes me nervous and would make
the launch of a page depending on this stressful. I'm not saying I know
the solution but I bet someone here does.

People like Richard Cornford, who may actually have the experience and
knowledge necessary to solve the quirks you are experiencing, object to the
entire idea of writing a general-purpose position-finding function. And in
cases where he finds a flaw in existing code (like mine) he is cryptic about
the problem and reluctant to give advice. He's just one example - there are
other people who could offer support in writing such a function also, but
object to the very concept of writing such a function.

Richard has completely convinced me about the value of layers of
JavaScript. Solutions for the simple cases and then building more
complex cases on top or as separate modules with the same API. I am
sure I don't I implement his idea with finess but already my code has
become much cleaner and more organized and I am more proud of my code.
I am grateful for his advice.

From what I have read here, I think that the people here that are

reluctant to offer suggestions for a general purpose library have good
reason. I think the existing code libraries advertise that they do it
all and are general purpose when in fact they are not. They make people
think that writting JavaScript will be easy because the libraries
smooth out all the bumps. Perhaps the reluctance to offer suggestions
is a backlash of "I told you so" to show people that JavaScript is not
a toy language and good browser scripting is hard.

I think it would be better to have a library that explains under which
limited circumstances a particular function will work.

I have been reading the code in many JavaScript libraries as a learning
experience. It is really valuable and the better the code the more I
learn. But if the really hard won tricks that the gurus know about,
like position reporting, are kept secret it makes my learning harder
and slower. It is the same situation for other people that genuinely
want to learn too and ultimately more bad JavaScript ends up on the web
without the sharing of the really great tips.

"If I have seen a little further it is by standing on the shoulders of
Giants." - Newton

But, of course, he who figures out one of these hard won secrets has
the right to keep it. Job security.

I've always been in favor of the experts of this group pooling their
knowledge and resources into writing solid, bullet-proof low-level functions
for very basic tasks that work across as many browsers and situations as
possible. There seems to be little interest.

Unfortunate. I bet that even the experienced ones here could learn by
collaborating on something difficult like position reporting. They
would, of course, have to expose just how expert they really are. (I
don't mean that comment directed at any particular person or
sarcastically.)

I would like to read more articles like this

At the very least, libraries like my Object Position and others improve on
the very flawed approach of just walking up the offsetParent chain and
adding up the offset values. That's the typical approach shown on sites like
Quirksmode, and wouldn't even come close to giving you the correct answers
in your test case!

I agree but I sure would like to see the browser sniffing out of an
example like yours, Yahoo! UI or Prototype.js that try to fix browser
bugs/differences.

If you find the solution to your problem or if anyone else can offer advice
on how to improve my code to handle more browser quirks and specific
situations, I would of course love to hear it.

I also.

Unifying event listeners and ajax across the browsers seems managable.
Opacity is without sniffing seems harder. But proper position reporting
seems like a real killer.

- Peter