W3C home > Mailing lists > Public > www-style@w3.org > April 2008

Re: [cssom-view] padding edge / border edge for offsetTop/offsetLeft?

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Fri, 25 Apr 2008 10:52:29 -0700
Message-ID: <c9e12660804251052m64ec9778q52d124cbe68893c2@mail.gmail.com>
To: "Sylvain Galineau" <sylvaing@microsoft.com>
Cc: "Mike Wilson" <mikewse@hotmail.com>, Www-style <www-style@w3.org>

On Fri, Apr 25, 2008 at 9:05 AM, Sylvain Galineau
<sylvaing@microsoft.com> wrote:
>
>  > 1) IE does it this way.
>  This is probably the main source of confusion on my side; my strict-mode tests with IE7/IE8 show parent outer-border-edge to element outer-border-edge; same with Opera. Safari and Firefox behave as currently specified in CSSOM-View.
>
>
>
>
>  > 2) It's compatible with CSS 2.1's positioning with left/top
>  >    attributes for position:absolute elements.
>  >    I e, if you have an absolutely positioned element that
>  >    you assign
>  >      left:10px
>  >    to, then offsetLeft will also return 10 as the offset is
>  >    measured from the same points (padding edge to border edge)
>  >    as used by CSS positioning. Of course assuming here that the
>  >    offsetParent and Containing Block elements are the same,
>  >    which they usually are in standards-mode IE, but not in the
>  >    current CSSOM proposal.
>  This is good background, thank you.
>
>
>  > This is of course only a problem if the elements have border>0
>  Correct.
>
>
>  > and is a problem that would have appeared for IE users a long
>  > time ago if pages depended on it.
>  Unless IE goes border-edge to border-edge in which case it worked whether borders were present or not.
>
>
>
>  > And as Garrett showed there
>  > are scripts that correctly add border and scroll.
>  Garret's script is all-around remarkable in both its thoroughness and size. That such effort is needed to compute offset should indicate we have a very broken API, imo. I may be wrong but aren't Garret's disagreements essentially a statement that we are about to entrench this, or worse ? Backward compatibility is a worthwhile goal, but if the end result requires this much effort to get the proper answer, maybe those who think we should move on and get the ClientRect APIs right have a point.
>

My disagreements with standardizing offset* are:
0) CSSOM is not test driven. Need a test suite for offset* before
sitting down and writing a spec.
1) informal, ad hoc examples and discussions show that a standard will
require changes to existing implementations (browsers) that have
dependencies (millions of pages)
2) the way that offset* are standardized in CSSOM WRT the BODY element
is unintuitive, makes body special in a bad way, and contradicts other
browsers except Opera when:
<!doctype html>
<body style="position: relative;" onload='alert(a.offsetTop)'><div
id=a style="position: relative"></div></body>

Result: 0 in all browsers, except in Opera.
Result in Opera: 8.

Opera follows CSSOM Views algorithm, measuring from - a - to viewport edge.

The IE offset* properties were useful in some cases, but, as Anne's
example shows, can have surprising results depending on the
width/height and position properties. Even in IE.

Anne's example in this thread above shows that when a div does not
have width/height, it uses a static containing block for it's
offsetParent. This is shown in Anne's example#1, where we can see that
offsetParent is DIV.

javascript:alert(x.offsetParent.tagName)

<!doctype html>
<style>
 body { margin:0 }
 div { border:10px solid; height:100px; width:100px }
 div#x { border:20px solid orange; height:10px; width:20px }
</style>
<div><div id=x></div></div>

with

<!doctype html>
<style>
 body { margin:0 }
 div { border:10px solid  }
 div#x { border:20px solid orange; height:10px; width:20px }
</style>
<div><div id=x></div></div>

In example #2, we can see that the offsetParent is BODY.

Mike Wilson's example from another thread showed that an offsetParent
can have static position, when the node in question has no
width/height. That example wasn't properly acknowledged.

Some confusion must have lead to Anne's assumption that hasLayout
determines this behavior. In fact, that claim is provably false.

<!doctype html>
<style>
 body { margin:0 }
 div { border:10px solid  }
 div#x { border:20px solid orange; zoom:1 }
</style>
<div><div id=x></div></div>

javascript:alert(x.offsetTop + ", " + x.currentStyle.hasLayout)

IE7 => 10, true

Shows that the offsetTop includes the parentNode's border-width and
also has a layout.

<!doctype html>
<style>
 body { margin:0 }
 div { border:10px solid; display: }
 div#x { border:20px solid orange;  inline-block;  }
</style>
<div><div id=x></div></div>


Changing offset* to be useful sounds like a good idea, but since
offset* is complicated by surprises in IE's implementation and bugs in
other implementations, it would not be possible to do it without
breaking sites and adding more confusion to the mess.

Garrett


>  Sylvain
>
>
>
Received on Friday, 25 April 2008 17:53:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:05 GMT