9844 - RFE: No way to find size/position via DOM

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, enhancement, P3)

Description

[Doyle Davidson]

I understand that the DOM-1 spec & DOM-2 proposal don't included anything about
size and position - but there needs to be a way to determine the position and
size of any arbitrary element via JavaScript accessing the DOM.  Obviously this
information is already internally known for the purpose of events.  We have
several needs for this information (a lot of run-time object dragging/sizing).

Comment 1

[Micah Dubinko]

*** Bug 7438 has been marked as a duplicate of this bug. ***

Comment 2

[vidur (gone)]

Working with the DOM Working Group to come up with a standard way of doing this.
It might just be a copy of IE's offsetTop, offsetLeft, etc. properties.

Comment 3

[ekrock's old account (dead)]

Moving to M13 and DOM2 Component. (It's really a "DOM3" issue.)

Comment 4

[Daryl Lee]

Since I'm quite interested in this enhancement, I've made a patch.

As you noted I made it similar to the IE4+ set of properties. I added another
interface to most of the HTML Elements called INSElementPosition. It implements
offsetTop, offsetLeft, offsetRight, offsetBottom and offsetParent, by looking
them up from the primary frame attached to that Content object. It returns the
values in pixels.

For offsetTop it returns the frame's GetParent()

This is essential for developers of web apps, so I'm looking forward to having
this feature included. Looking forward to any comments or questions.

The patch is in 4 different sections one for each of the folders: caps, dom,
layout, xpcom

Comment 5

[Daryl Lee]

Attachment: Proposed patch (caps folder)

Comment 6

[Daryl Lee]

Attachment: Proposed patch (dom folder)

Comment 7

[Daryl Lee]

Attachment: Proposed patch (layout folder)

Comment 8

[Daryl Lee]

Attachment: Proposed patch (xpcom folder)

Comment 9

[Daryl Lee]

Sorry there was a mistake there:

offsetTop, offsetLeft etc... return the difference in pixels between this
element and the offsetParent element.
offsetParent returns the content assoctiated with the frame's parent eg:
nsIFrame->GetParent()

Comment 10

[vidur (gone)]

Moving to M14, but I will get this in before beta. Thanks for the patch
Daryl - I will review it. Eric, can you live with that?

Comment 11

[ekrock's old account (dead)]

"Live with" this? Heck yes, this is outstanding! The most I was hoping for was
to get this in by M16, so if we can get in in by M14, so much the better!

Absolutely agree with being compatible with IE5 on these positioning properties
where no standard exists. Thanks a million to Daryl and Vidur both!

Comment 12

[Daryl Lee]

You're welcome. Glad I could be of a help.

FYI, I found that there is one minor difference in behavior between this patch
and IE4/5. It has to do with offsetParent. IE4/5 doesn't treat certain elements
as offsetParents. For example the P tag doesn't get in the heirarchy and there
are others.

For offsetParent (I think) each and every  displayable (or flowable) element
comes into play, because it's based on nsIFrame->GetParent().

Not that this is a major problem. I mean, to figure out the position of an
element from the top of the page you need to write recursive code either way.

I got a testcase somewhere that I was fiddling around with that demonstrates
this. I'll post it. Just increbibly busy right now.

Comment 13

[Daryl Lee]

Attachment: Test case for differences between patched Mozilla and IE

Comment 14

[Daryl Lee]

Attachment: Patch for Milestone 12: The above patches combined in one file

Comment 15

[vidur (gone)]

Checked in an implementation based on Daryl Lee's patches. I added a few things:
1) width and height needed to take into account continuation frames.
2) left and top need to be relative to an offsetParent (generally the BODY 
element to be compatible with IE)
3) left and top need to be inside the border, but outside the padding

I couldn't find a definitive statement on what the offsetParent is for all types 
of elements in IE. For now, the BODY element is always the offsetParent for 
elements in a HTML document (I know, however, that the offsetParent for a TD is 
the containing TABLE element in IE5).

I also temporarily added the new properties to the HTMLElement interface rather 
than create a new one. I did't want to introduce the cost of a new interface (an 
additional 4-byte vtable pointer) on all content at this point. I'll consider 
alternatives in an upcoming content slimming exercise.

Comment 16

[vidur (gone)]

Attachment: a test case for the new properties (click on any part of the document)

Comment 17

[Robert E. Boughner]

The offsetTop and offsetLeft values do not always contain meaningful data.  The 
two examples submitted here demonstrate this.  The first example has a DIV 
wrapping an Unordered list and when the mouse moves over the layer (colored 
yellow) an alert box dumps the properties associated with the DIV. Here the 
offsetTop and offsetLeft values are null.  The second example is the same 
except here parts of the unordered items are contained in a SPAN tag.  The first 
one (colored blue) returns offsetTop = null and a valid offsetLeft.  The second 
item colored red return meaningful offsetTop and offsetLeft values.  These 
examples were run using the M14 build on a Windows 98 machine.

Comment 18

[Robert E. Boughner]

Attachment: Example One -- HTML source code demonstrating the problem

Comment 19

[Robert E. Boughner]

Attachment: Example Two -- HTML source file demonstrating the problem

Comment 20

[Robert E. Boughner]

Forgot to mention that IE 5.0 returns values for offsetTop and offsetLeft in 
both these examples.

Comment 21

[Myk Melez [:myk] [@mykmelez]]

See bug 29449 for an additional situation in which an offset property is not
being set.  Should this bug be reopened or should new bugs be filed on these
problems?

Comment 22

[ekrock's old account (dead)]

All -- Though I'm too swamped right now with beta1 PDT+ issues to investigate 
each attachment, it sounds like you are reporting specific bugs with the support 
for getting size/position that we now have checked in, as opposed to the 
complete lack of support we had earlier. So please open a separate bug report 
for each individual problem to ensure each issue is tracked individually through 
to resolution confirmed by QA. The Golden Rule of Bugzilla is One Report == One 
Issue. Thanks a million for your continuing work and testing on this!!!

Comment 23

[Joe Hewitt]

May I suggest that the resolution of this bug should not be "FIXED", because it 
is not fixed.  the offset* properties exist now, but they don't always work.  I 
will attach some test cases soon to demonstrate where they fail...

Comment 24

[ekrock's old account (dead)]

Joe, thanks for the info. If you find bugs, by all means we want to know, but 
*don't* attach them to this bug. Instead, open a new bug report for each issue 
(one issue == one bug report --the Golden Rule of Bugzilla) and attach the test 
cases to those. That will assure each bug gets individual attention as it 
deserves and that each one can be passed around independently as needed. Thanks!

Comment 25

[Boris Zbarsky [:bzbarsky]]

*** Bug 69787 has been marked as a duplicate of this bug. ***

Comment 26

[Sivakiran Tummala]

verified 11-03-08