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

Re: Fwd: cssom - clientTop, et v

From: Anne van Kesteren <annevk@opera.com>
Date: Sun, 09 Mar 2008 23:29:29 +0100
To: "Garrett Smith" <dhtmlkitchen@gmail.com>, Www-style <www-style@w3.org>
Message-ID: <op.t7rsrfmw64w2qv@annevk-t60.oslo.opera.com>

On Sun, 09 Mar 2008 23:11:32 +0100, Garrett Smith <dhtmlkitchen@gmail.com>  
wrote:
>>  Given that there's already getComputedStyle and the CSSOM tries to
>>  introduce Element.currentStyle I don't think any of these is needed.
>
>  There are two problems I have with that last statement.
>
>  The most obvious problem is that currentStyle does not return a pixel
>  value; clientTop does. The hypothetical borderTopWidth would also
>  return a css pixel value. So in fact, the currentStyle does not solve
>  the problem.

CSSOM had at one point some proposals for even more advanced trickery. So  
you could do:

   element.currentStyle.borderRightWidth.px

but that's abandoned for now.


> [edit]
> To clarify, clientTop returns a pixel value as a rounded number. The
> hypothetical borderTopWidth would return a css pixel value parsed as a
> float. currentStyle is expected to return a string that includes the
> unit.
> [/edit]

True, you'd have to parse the currentStyle return value. Much the same  
goes for getComputedStyle.


> [...]

Yes, specyfing currentStyle is hard :-) It's currently a red box. Same  
goes for getComputedStyle fwiw as it typically works with the CSS 2  
definition of "computed style' rather than that of CSS 2.1...


>  These properties are useful for getting an element's position,
>  distance from ancestor, The parentNode of the targetted element may
>  have a border. In this case, the targetted element's position would be
>  offset by its parentNode's border (Opera incorrectly added this number
>  into offsetTop, as per your spec, which has since been revised.)

Are you sure Opera changed its behavior at some point with respect to  
offsetTop and border stuff? I don't recall that happening.


>  Creating a useful API, to me, is a better goal than "copy". Existing
>  implementations can refactor their interfaces accordingly. For
>  example:
>
>  If the behavior of [some_new_property] mimics the behavior of
>  clientTop in [browser_x], then that browser will have a simple task.
>  If the behavior of [some_new_property] doesn't mimic clientTop in
>  [browser_x], then that browser will have a new property to add.
>
>  A new API, to me, seems much better than "copy and make incompatible."

A new API doesn't solve any problems we have with the existing APIs. It  
just adds more. Whether we like it or not, clientTop is part of the Web.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
Received on Sunday, 9 March 2008 22:29:29 GMT

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