#15 DynAPI3: get the x and y offset of the document

[snuryscott]

Suggestion in dyndocument.js:

p.pageYOffset = function() {
return
dynapi.ua.ie?document.body.scrollTop:window.pageYOffset;
}

p.pageXOffset = function() {
return
dynapi.ua.ie?document.body.scrollLeft:window.pageXOffset;
}

Logged In: YES
user_id=706287

Well, looking over these old tracker submissions after the
dynapi-3.0.0-beta2 release.

Currently, DynAPI seems to use functions called getPage[XY]
which are initially set up in dynlayer_base.js and
overwritten in dynlayer_ns4.js.

dyndocument sets getPageX and getPageY to dynapi.functions.zero.

Let's look at packages.js for a moment.

26:// API - Core Events & DynDocument
...
29:l.add('dynapi.api.DynDocument','dyndocument.js','DynEvent');
30: // DynLayer
31:l.add('dynapi.api.DynLayerBase','dynlayer_base.js','DynDocument');

If I understand the packages loading properly, then
DynDocument does not use, or load, or have it's prototype
set to DynLayer, therefore it does not inherit getPage[XY]
from DynLayer. However, DynLayer does seem to require
DynDocument to be loaded.

So I wonder a few things. Does it make sense to have
DynDocuments know their page offsetts? I wonder why the
functions were set to zero in the first place. It seems
counter intuitive.

Second, if we make a change, is it as simple as moving the
initial getPage[XY] definitions to dyndocument.js? Would
this break anything? From what I understand at a glance, it
would be fine. Anything that currently requires these
functions must use a DynLayer. DynLayer already uses
DynDocument. So it should be transparent.

Anyone else have any ideas? I'll attempt some basic
testing. But I want to know what conditions to test to
ensure the modification yields robust performance.