Re: [cssom-view] Why is body's offsetParent null ?

On Wed, Apr 23, 2008 at 3:09 PM, Mike Wilson <mikewse@hotmail.com> wrote:
>
>  Hi Sylvain,
>
>  I realize your original question was sort of lost so I'll give
>  my 2 cents on that first:
>
>
>  > The current spec and user agents I have tested - IE7, FF3b5,
>  > Safari 3.1, Opera 9.5b1 -  set body's offsetParent property
>  > to null even though a) body has offset properties for which
>  > b) there is a reference element - html - with box properties
>  > of its own.
>  >
>  > My question is : what are the reasons for this beyond
>  > compatibility with IE legacy ?
>
>  If we agree that
>   a) the other browsers algorithms are aimed at cloning IE and
>      not inventing something new
>   b) majority of existing deployed content is made for IE
>      algorithm(s)
>  then both these factors are part of the IE legacy. Therefore
>  I would say that body.offsetParent==null is all about IE legacy.
>
>
>  > Afaik, it is practically always null today; but in IE8b1's
>  > standards mode, it refers to html. From an API design and
>  > object model standpoint, the latter is what the caller
>  > expects, imo.
>
>  Yeah, this is what I also believe would be the natural thing if
>  designing the API from scratch.
>
>
>  > As mentioned by others earlier, simple list-walking patterns
>  > such as the one below from Prototype's dom.js are fairly common :
>  >
>  > cumulativeOffset: function(element) {
>  >     var valueT = 0, valueL = 0;
>  >     do {
>  >       valueT += element.offsetTop || 0;
>  >       valueL += element.offsetLeft || 0;
>  >       element = element.offsetParent;
>  >     } while (element);
>  >     return Element._returnOffset(valueL, valueT);
>  >   },
>
>  [nit-picking note:]
>  Aren't they forgetting to add the border from the "middle"
>  visited elements?

Of course. The example is useful only for the example. It would not
actually work, despite claims by Anne or PPK, it would fail a good
portion of the time.

Such script would yield inaccurate results in every browser because
(1) the script does not take into account offset from a parent node's
border width and (2) it doesn't account for scroll offsets. jQuery
offset and YUI's Dom.getXY take both of these into consideration. My
own script does too:
http://dhtmlkitchen.com/ape/example/dom/getOffsetCoords.html

For reasons creative or otherwise,a bug was introduced into a prior
edition of CSSOM Views spec to ameloirate, or address the
"border-not-included" concern. This broke compability in every other
browser and the scripts reflect that. The bug was along the lines of:

|  offsetTop - returns the distance between the element's border edge
and the border edge of the element's offsetParent.

This was a mistake (and probably a deliberate one). But has since been
changed in the spec. THe script:-

 while (ele != document.body) {
   t += ele.offsetTop
   ele = ele.offsetParent

 }

- Would take more into consideration, but still omits the borders and
scroll offsets.

It surprised me that anyone who has been following this thread might
still believe that that script actually works.

>
>
>  > ..and our first IE8 Beta may have pulled this rug by a number
>  > of pixels for a number of web sites. Some of us at Microsoft
>  > judge this to be a welcome fix to a long-standing bug, while
>  > others - and I am among the latter - see it as a regression
>  > from a de-facto standard behavior.
>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html>
<head><title>hey</title></head>
<body onload="window.a = document.getElementById('a');
alert(a.offsetParent.tagName + a.offsetTop)">
<div id="a" style="position: relative; top:10px"></div>
</body>
</html>


Would alert "HTML25" in IE7, "BODY18" for CSSOM (body margin is
different by default)

The number comes from "10" + [body margin].

Q: Should offsetParent be "HTML", "BODY", null, or something else?

1) If null, then it would mean that the offsetTop of a would have to be 0.
2) If BODY, then the offsetTop would have to be 10
3) if HTML, then the offsetTop would be 10 + body margin.

>  Are you only looking at the algorithm in the new super-standards
>  mode, or would this also be changed for the "IE7" standards mode
>  in IE8?
>
>
>  > To the extent possible, I am looking for informed opinion as
>  > well as any data - web sites, frameworks, assumptions
>  > explicitly or implicitly stated in related standards - that
>  > can give us a better measure of the decision.
>

To use HTML breaks consistency in that HTML is not going to be
positioned. However, the result is not as bad as with the other two
options. offsetTop returns the distance between the element's border
edge and the padding edge of it's offsetParent. If BODY is used, that
measurement goes wrong most of the time, because BODY has a margin by
default.

[snip]

>  Best regards
>  Mike Wilson
>
>
>

Received on Wednesday, 23 April 2008 23:21:04 UTC