- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Fri, 11 Apr 2008 20:59:56 -0500
- 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. Yes. > 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 thing. 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 things.... > 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. -Boris P.S. Good to see we're back to actual technical issues here.
Received on Saturday, 12 April 2008 02:00:40 UTC