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>  
>>  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:


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
Received on Sunday, 9 March 2008 22:29:29 UTC

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