Fwd: cssom - clientTop, et v

Whoops, this got off the list again. I have to clarify something I wrote. [edit]


---------- Forwarded message ----------
From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Sun, Mar 9, 2008 at 1:08 PM
Subject: Re: cssom - clientTop, et v
To: Anne van Kesteren <annevk@opera.com>


On Sun, Mar 9, 2008 at 12:10 PM, Anne van Kesteren <annevk@opera.com> wrote:
 > On Sun, 09 Mar 2008 20:39:58 +0100, Garrett Smith <dhtmlkitchen@gmail.com>
 >  wrote:
 >
 > > There is no way to get the border-right and border-bottom widths.
 >  >
 >  > clientTop - border-top-width
 >  > clientLeft - border-left-width
 >  > _______  - border-right-width?
 >  > _______  - border-bottom-width?
 >
 >  True, it's not entirely clear to me what the use cases are for these.

 It comes back to that problem of finding an element's position.


 It
 >  made sense to add them to the specification mostly because every had them.
 >
 >
 >
 >  > The other problem with the client* properties is that they are rounded
 >  > pixel values (at least in IE, Opera, and Safari).
 >
 >  All APIs in the CSSOM View Module basically give dimensions / coordinates
 >  in CSS pixels.

 The compatibility problems may arise in pages attempting to do numeric
 comparison based on int values.

 if(el.clientTop == 1) {

 }

 where the new API could return a floatint point number: .99






 >
 >
 >
 >  > The other problem I have is the name. "clientTop" does not describe a
 >  > borderTopWidth.
 >  >
 >  > Would it make sense to:
 >  >
 >  > 1) include widths for ALL borders?
 >  > 2) include floating point pixels (sub-pixels) (to avoid cumulative
 >  > rounding issues mentioned in earlier msg)
 >  > 3) renames these properties to something non-conflicting so as to
 >  > avoid compatibility issues with (2)?
 >
 >  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.

[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]

 The second problem I'm sure you already know what I'm going to say. I
 feel as if I'm being led.

 Trying to standardize IE's currentStyle will lead to compatibility
 issues. It will also make writing webapps harder.

 I didn't expect to get drawn into a side topic, this makes it harder
 to make my original point of the problem with clientTop. We'll get
 back to that. There is just such an overwhelming number of problems.
 Problems in the spec, in the process it was conceived, in existing
 implementations.

 <currentStyle diversion>

 Off the top of my head, keyword values like "inherit", "auto",
 "medium" shorthand values. These cases require special consideration
 and thorough testing with existing implementations. And clip (which is
 broken in IE, e.g. - el.clipTop, et al).

 Creating a property - cascadedStyle - would allow authors to choose
 between standard and legacy

 if(el.cascadedStyle) {

 }
 else if(el.currentStyle) {

 }

 currentStyle for Opera is severly broken. It floors some values (but not all).
 currentStyle for IE is not specified clearly enough when it comes to
 "auto" or shorthands, et c. This is more serious because there are
 cases where pages may depend on a certain value for currentStyle.

 If currentStyle is specified in a way that is incompatible with IE, it
 will break pages that rely on values returned by IE. It will make page
 authoring harder.

 Creatinga new property - cascadedStyle - avoids these problems.

 </currentStyle diversion>

 Now, to get back to the original topic, you had stated : -

" True, it's not entirely clear to me what the use cases are for these. It
 made sense to add them to the specification mostly because every had them."

 -
 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.)

 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."


 Garrett

 >
 >  --


>  Anne van Kesteren
 >  <http://annevankesteren.nl/>
 >  <http://www.opera.com/>
 >

Received on Sunday, 9 March 2008 22:11:44 UTC