Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
The reference implementation has a "par" property off the geometry object that is passed to the safe frame contents. This is not reflected in the spec. In the next spec version we should formalize this property.
Yes allow me also to explain this a bit better (5 months after this original post :P).
The "par" object carries the rectangle information for what the SafeFrame host code considers a given SafeFrame's controlling view-port is. . .
So for example you may render a SafeFrame directly within a BODY element in your web page.
In this case the view-port is the browser window/BODY element. In turn the element to calculate how much expansion can happen, and whether or not a particular SafeFrame is actually in-view or not is said BODY element, so we report you the rectangle information of that element as well.
Now keep in mind, that sometimes the controlling view-port is NOT the browser window.
Sometimes it may be say a DIV in the page that has it's own scrollbars.
In that case, "par" is the rectangle of said DIV.
Either way, the "par" rectangle is then used to calculate the values in "exp".
We also have (or will have) "root" which is a boolean telling you whether or not par is the main window view port vs some other element.
The "exp" values also get adjusted depending on a view-port's current scroll location.
So for example if you render a SafeFrame totally below the fold in the BODY element,
assuming no other overlapping elements or parent elements with clipping over overflow hidden, exp.t could still be really big b/c we are basically telling you that you have ALOT of room to expand to the top.
But at the same time, if you scrolled that SafeFrame into view, exp.t would get smaller,
b/c while the page can scroll, we ideally don't want you to do an expansion that would in turn force a scroll action.