Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Javascript (http://www.velocityreviews.com/forums/f68-javascript.html)
-   -   Find Element Position (http://www.velocityreviews.com/forums/t934721-find-element-position.html)

dhtml 02-17-2008 10:09 PM

Find Element Position
 
I've set off to the task of finding an element's position.

getOffsetCoords( el, container, coords );

container (optional) is any ancestor of el.
coords (optional) an object that has x and y properties - { x: 0, y :
0 }

I'm including scroll widths and borders of parentNodes.

This is useful for widgets like tooltip, dragdrop, context menu.

I'm throwing this up here for people to pick apart.

Areas that need improving:
* find cases where it fails
* find inefficiencies
* find things that can be improved
* formatting, or any other annoyances

Source:
http://dhtmlkitchen.com/ape/src/dom/position-f.js

testcase (I have not tested in IE6 (only 7))
http://dhtmlkitchen.com/ape/test/tes...on-f-test.html


Matt Kruse 02-17-2008 10:43 PM

Re: Find Element Position
 
On Feb 17, 4:09 pm, dhtml <dhtmlkitc...@gmail.com> wrote:
> I've set off to the task of finding an element's position.


Were none of the 500 existing solutions sufficient? :)

Matt Kruse

Peter Michaux 02-17-2008 10:57 PM

Re: Find Element Position
 
On Feb 17, 2:09 pm, dhtml <dhtmlkitc...@gmail.com> wrote:
> I've set off to the task of finding an element's position.


That is a long road if you don't set some very strict limits on what
kind of elements with what kind of ancestors and what kind of doctypes/
quirksmode. Just scrolling elements in a table on a Strict page screws
up half the functions out there. Did you notice that the difference
between mouse position of an event and element position in IE are 2px
different. The "bezel" around the viewport window (i.e. the part of
the browser where the page is displayed) looks like it is about 2px.
The problem is basically a mess.

Look for posts in the archives where Matt Kruse and Richard Cornford
argue about even the idea of having a single general solution to the
position reporting problem. Matt argues it is a good idea to have a
single solution but Richard says that even if the solution could be
written it would be huge and slow. Richard seems to have explored the
oddities of this problem in great depth and has decided to have a set
of interchangeable functions/modules with the same api. Each version
suited to a different set of circumstances. This is a concept that has
interested me quite a bit recently. This is one of the main c.l.js
long term battles since I've been reading the group for a couple
years.

A good first question is why do you need to know where the element is
on the page? I have never needed to know this. For drag-drop work a
position relative to the parent element is plenty.

Peter

dhtml 02-17-2008 10:57 PM

Re: Find Element Position
 
On Feb 17, 2:43 pm, Matt Kruse <m...@mattkruse.com> wrote:
> On Feb 17, 4:09 pm, dhtml <dhtmlkitc...@gmail.com> wrote:
>
> > I've set off to the task of finding an element's position.

>
> Were none of the 500 existing solutions sufficient? :)
>

No, most of them make assumptions about body being an offsetParent.

Might want to check yours in Mozilla and Opera. Add some scroll left,
and scroll on body:
http://www.javascripttoolbox.com/lib...n/examples.php

It fails for me in both FF 2 and Opera 9.2

And that's not even adding any border or setting position: relative on
body.

Garrett

> Matt Kruse



David Mark 02-17-2008 11:36 PM

Re: Find Element Position
 
On Feb 17, 5:09*pm, dhtml <dhtmlkitc...@gmail.com> wrote:
> I've set off to the task of finding an element's position.
>
> getOffsetCoords( el, container, coords );
>
> container (optional) is any ancestor of el.
> coords (optional) an object that has x and y properties - { x: 0, y :
> 0 }
>
> I'm including scroll widths and borders of parentNodes.


Watch out for Opera with regard to borders.

>
> This is useful for widgets like tooltip, dragdrop, context menu.
>
> I'm throwing this up here for people to pick apart.


I don't have time at the moment to pick it apart, but I can tell you
from experience that just getting the major browsers to work in most
cases (nobody has time to test every possible case) requires a lot of
feature testing (e.g. create a div, style it in a way known to cause
issues in some browsers, append it to the document, check various
properties against expected results, etc.) There are numerous
examples of this in my library. I can't remember if you are one of
the people who received a link to the Alpha. (?) I plan to make a
similar "pick apart" request here for the Beta version.

>
> Areas that need improving:
> ** find cases where it fails
> ** find inefficiencies
> ** find things that can be improved
> ** formatting, or any other annoyances
>
> Source:http://dhtmlkitchen.com/ape/src/dom/position-f.js
>
> testcase (I have not tested in IE6 (only 7))http://dhtmlkitchen.com/ape/test/tes...on-f-test.html


If you use getBoundingClientRect when available, IE6/7 get virtually
the same results. The code to deal with the "bezel" (border of the
outermost element) issue that Peter mentioned is in my script. One
upcoming issue with that is that other browsers (e.g. the new Opera)
are starting to implement getBoundingClientRect and I wonder if they
will stay true to IE's version. IIRC, the W3C is working on a
standard for this method.

Similarly, getBoxObjectFor is very helpful with Gecko and Mozilla-
based browsers, though it has some very odd quirks related to
scrolling containers with borders.

Everything else must use the typical offsetParent loop and that is
where most of the feature test results come into play. For instance,
Opera alone includes border widths in offsetLeft/Top. Feature test
this and you don't have to worry if they change that in the future (or
other browsers start to follow their lead.) Personally, I consider
this a bug, despite the absence of a standard for the offset*
properties (the client* properties are there to measure borders.)

David Mark 02-17-2008 11:38 PM

Re: Find Element Position
 
On Feb 17, 5:43*pm, Matt Kruse <m...@mattkruse.com> wrote:
> On Feb 17, 4:09 pm, dhtml <dhtmlkitc...@gmail.com> wrote:
>
> > I've set off to the task of finding an element's position.

>
> Were none of the 500 existing solutions sufficient? :)
>


I've never seen one that is close, even for commonly used DOM
structures. Once you start testing cases like fixed positioned,
scrolling containers with borders in quirks mode with borders on the
body element, they completely fall apart as most rely on browser
sniffing in lieu of proper feature testing.

David Mark 02-17-2008 11:42 PM

Re: Find Element Position
 
On Feb 17, 5:57*pm, dhtml <dhtmlkitc...@gmail.com> wrote:
> On Feb 17, 2:43 pm, Matt Kruse <m...@mattkruse.com> wrote:> On Feb 17, 4:09 pm, dhtml <dhtmlkitc...@gmail.com> wrote:
>
> > > I've set off to the task of finding an element's position.

>
> > Were none of the 500 existing solutions sufficient? :)

>
> No, most of them make assumptions about body being an offsetParent.
>
> Might want to check yours in Mozilla and Opera. Add some scroll left,
> and scroll on body:http://www.javascripttoolbox.com/lib...n/examples.php
>
> It fails for me in both FF 2 and Opera 9.2
>
> And that's not even adding any border or setting position: relative on
> body.
>


Yes, that solution completely ignores border issues.

A relatively positioned body element? Now there's an odd test case.
Never thought to try that one, but I don't think it would be an issue
with mine (relative positioning works fine for other elements.)

From looking at one of your recently posted examples, I suspect I need
to add a couple of additional feature tests related to tables, but
they should only affect agents that implement neither
getBoundingClientRect or getBoxObjectFor.

David Mark 02-17-2008 11:53 PM

Re: Find Element Position
 
On Feb 17, 5:57*pm, Peter Michaux <petermich...@gmail.com> wrote:
> On Feb 17, 2:09 pm, dhtml <dhtmlkitc...@gmail.com> wrote:
>
> > I've set off to the task of finding an element's position.

>
> That is a long road if you don't set some very strict limits on what
> kind of elements with what kind of ancestors and what kind of doctypes/
> quirksmode. Just scrolling elements in a table on a Strict page screws
> up half the functions out there. Did you notice that the difference


Then those aren't really solutions at all.

> between mouse position of an event and element position in IE are 2px
> different. The "bezel" around the viewport window (i.e. the part of
> the browser where the page is displayed) looks like it is about 2px.


See my code, specifically the getBoundingClientRect branch.

> The problem is basically a mess.


No question.

>
> Look for posts in the archives where Matt Kruse and Richard Cornford
> argue about even the idea of having a single general solution to the
> position reporting problem. Matt argues it is a good idea to have a
> single solution but Richard says that even if the solution could be
> written it would be huge and slow. Richard seems to have explored the
> oddities of this problem in great depth and has decided to have a set
> of interchangeable functions/modules with the same api. Each version
> suited to a different set of circumstances. This is a concept that has
> interested me quite a bit recently. This is one of the main c.l.js
> long term battles since I've been reading the group for a couple
> years.
>
> A good first question is why do you need to know where the element is
> on the page? I have never needed to know this. For drag-drop work a
> position relative to the parent element is plenty.


Not if you want to drag or position elements over a statically
positioned element. This is covered in the unit tests for my drag and
drop module. The test involving a statically positioned element is
not included unless the offset module is present. Same for the drop
target test. You could handle drop targets without calculating
offsets if the dragged element and target share the same positioned
parent, but that isn't possible for all applications. Also, some of
the quirks discussed here (e.g. borders in Opera) come into play for
statically positioned targets, whether an offset from the document
origin is needed or not.

dhtml 02-17-2008 11:57 PM

Re: Find Element Position
 
On Feb 17, 3:36 pm, David Mark <dmark.cins...@gmail.com> wrote:
> On Feb 17, 5:09 pm, dhtml <dhtmlkitc...@gmail.com> wrote:
>


> Watch out for Opera with regard to borders.
>

Covered.

>
>
> > This is useful for widgets like tooltip, dragdrop, context menu.

>
> > I'm throwing this up here for people to pick apart.

>
> I don't have time at the moment to pick it apart, but I can tell you
> from experience that just getting the major browsers to work in most
> cases (nobody has time to test every possible case) requires a lot of
> feature testing (e.g. create a div, style it in a way known to cause
> issues in some browsers, append it to the document, check various
> properties against expected results, etc.) There are numerous
> examples of this in my library. I can't remember if you are one of
> the people who received a link to the Alpha. (?) I plan to make a
> similar "pick apart" request here for the Beta version.
>

I'd like to see that.

>
> If you use getBoundingClientRect when available, IE6/7 get virtually
> the same results. The code to deal with the "bezel" (border of the
> outermost element) issue that Peter mentioned is in my script. One
> upcoming issue with that is that other browsers (e.g. the new Opera)
> are starting to implement getBoundingClientRect and I wonder if they
> will stay true to IE's version. IIRC, the W3C is working on a
> standard for this method.
>

Anne van Kesteren started CSSOM view module two years ago.
http://dev.w3.org/cvsweb/csswg/cssom...set-attributes

The document is mostly inaccurate. I've emailed him about this (and
his other inaccurate docs), but he is unable or unwilling to change.

> Similarly, getBoxObjectFor is very helpful with Gecko and Mozilla-
> based browsers, though it has some very odd quirks related to
> scrolling containers with borders.
>

https://bugzilla.mozilla.org/show_bug.cgi?id=340571

I'm going to look into getBoxObjectFor. If it's not buggy, it could be
a conditional:

else if(el.getBoxObjectFor) {

}

It might shoujld make it simpler and more efficient. I will
investigate.

> Everything else must use the typical offsetParent loop and that is
> where most of the feature test results come into play. For instance,
> Opera alone includes border widths in offsetLeft/Top. Feature test
> this and you don't have to worry if they change that in the future (or
> other browsers start to follow their lead.)


Yes, I have a load time constants in a closure. I do the feature
testing style you described in your prev paragarph.

Personally, I consider
> this a bug, despite the absence of a standard for the offset*
> properties (the client* properties are there to measure borders.)


It is as per Anne's spec. You should post on the css mailing list:
"www-style@w3.org" <www-style@w3.org>


dhtml 02-18-2008 12:06 AM

Re: Find Element Position
 
On Feb 17, 2:57 pm, Peter Michaux <petermich...@gmail.com> wrote:
> On Feb 17, 2:09 pm, dhtml <dhtmlkitc...@gmail.com> wrote:
>
> > I've set off to the task of finding an element's position.

>
> That is a long road if you don't set some very strict limits on what
> kind of elements with what kind of ancestors and what kind of doctypes/
> quirksmode. Just scrolling elements in a table on a Strict page screws
> up half the functions out there.

Can you provide some HTML testcase?

<table>
<caption>blah</caption>
<tbody>
<tr>
<td>

</td>
</tr>
</tbody>
</table>

Did you notice that the difference
> between mouse position of an event and element position in IE are 2px
> different. The "bezel" around the viewport window (i.e. the part of
> the browser where the page is displayed) looks like it is about 2px.
> The problem is basically a mess.
>

An element position from the viewport is offset by that border in IE.

This goes back to the difference between IE and Mozilla. IE calls HTML
the ICB, Moz treats viewport the ICB. IE in backcompat mode treats
BODY as the ICB. This is the big problem area.

> Look for posts in the archives where Matt Kruse and Richard Cornford
> argue about even the idea of having a single general solution to the
> position reporting problem. Matt argues it is a good idea to have a
> single solution but Richard says that even if the solution could be
> written it would be huge and slow. Richard seems to have explored the
> oddities of this problem in great depth and has decided to have a set
> of interchangeable functions/modules with the same api. Each version
> suited to a different set of circumstances. This is a concept that has
> interested me quite a bit recently. This is one of the main c.l.js
> long term battles since I've been reading the group for a couple
> years.
>

I will search that.

> A good first question is why do you need to know where the element is
> on the page? I have never needed to know this. For drag-drop work a
> position relative to the parent element is plenty.
>

For drag drop, I might have two different containers.

For a tooltip or context menu or panel, I might have any containers
surrounding the actuator/target.

Thank you,

Garrett

> Peter




All times are GMT. The time now is 05:05 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.