Re: [cssom-view] New WD "CSSOM View Module"

On Wed, Mar 5, 2008 at 9:48 PM, Robert O'Callahan <> wrote:
> One meta-comment: as an implementor, I am far more interested in getting the
> specification for getBoundingClientRect and getClientRects right than I am
> in the offset* properties, because I'm hoping that the former will take over
> on the Web and the offset* properties, with all their brokenness, will fade
> away. In fact if offset* was just removed from the CSSOM spec I would not be
> unhappy, although I applaud Anne's attempt to get it specified.

Hi Rob,

The attempt is ambitious. The current state of offset* in browsers is
a mess. When I first saw this, I thought it was admirable that Anne
attempted it -- and that's exactly what I told him in my first email
to him (quite some time ago and before this draft went public). I also
mentioned some of the problems.

It is a shame that an intelligent debate between us was not possible.

The issues I raised with offset* are still unresolved. I'd like to
upload some tests for a discussion point, and have those tests be
modifiable.  For any test, the expected outcome should be clear. I
think a test suite for offsetTop would help shed light on the matter.
I can say that in my own testing I have found a lot of inconsistencies
where the browsers try to work around the problem of the body element
being an initialOffsetParent, (a quirks mode feature, as it is defined
in the spec).

If the offset* properties do stay in the spec, they should make sense
and should not be contradictory.

Issues with getRect methods should be backed by tests, too.

Should these CSSOM properties respect sub-pixels, or should the round
or floor to an int? IE 7 rounds with floats:

John Resig took this further and provided a much better write up:

The IE offset* props don't seem to respect sub-pixels in browsers. In
order to get an exact coordinate measurement of an element, it is
necessary to have the pixel fractions. For example,take three border
widths (clientTop of 4 parentNodes ):-

1.4 + 1.4 + 1.4 + 1.4

- should the answer be 4, or 5.6 ?

The result of 4 would be inaccurate; this would be a miscalculation of
the target element's position.

For a drag operation based on such a calculation, the visual effect
would be an unsightly and possibly jumpy U/X.


> Rob
> --

Received on Thursday, 6 March 2008 08:30:21 UTC