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

Re: [cssom-view] small update

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Fri, 11 Apr 2008 20:59:56 -0500
Message-ID: <4800179C.3080502@mit.edu>
To: Garrett Smith <dhtmlkitchen@gmail.com>
CC: Www-style <www-style@w3.org>

Garrett Smith wrote:
> Even if offsetTop were reverse engineered accurately, which it isn't,
> it would still have problems.


> Does the abstract need a rewrite?

To be honest, the abstract should be the last part written, imo.  And even then, 
it will at best imperfectly capture what's going on.  That's the nature of absracts.

> 1) clientLeft/Top - is fine in a RTL world with only top/left
> positioning where pixels are rounded.

This is the same as offsetTop.  It needs to be specified for UA interop, but 
it's pretty poor as authoring APIs go.

> 2) no contentWidth or analagous property -
> 3) offsetTop/Parent is broken by design - can't reliably determine the
> distance between 2 arbitrary elements

I think the getBoundClientRect/getClientRects APIs cover all these issues, no?

> 5) unclear on whether a CSS Pixel will include decimal precision

Probably implementation-dependent, for what it's worth.  I would assume that 
anything that's |float| in the IDL will include whatever accuracy the UA can 
provide.  In that case of Gecko, say, that means it'll first be rounded to the 
nearest 1/60 of a CSS pixel and then rounded to the nearest floating-point 
number expressible on the architecture the browser is running on.  That sort of 

This does raise an interesting question.  The offset* properties are declared as 
floats in the IDL in the spec.  I don't think that's compatible with 
implementations, and worse yet it's not really compatible with content...

> Screen -
> These properties do not seem to have anything to do with the CSSOM abstract.

I guess I pretty much expect the abstract to have nothing to do with the meat of 

> Breaking all this down, rehashing it -- is time and energy consuming.
> ...."

I can see that.  Ideally, the above points would have made it into the relevant 
issues list.


P.S.  Good to see we're back to actual technical issues here.
Received on Saturday, 12 April 2008 02:00:40 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:35 UTC