Re: Fwd: cssom - clientTop, et v

On Sun, Mar 9, 2008 at 2:29 PM, Anne van Kesteren <annevk@opera.com> wrote:
> On Sun, 09 Mar 2008 23:11:32 +0100, Garrett Smith <dhtmlkitchen@gmail.com>
>  wrote:

>
>  CSSOM had at one point some proposals for even more advanced trickery. So
>  you could do:
>
>    element.currentStyle.borderRightWidth.px
>
Another diversion - a diversion from a diversion!

Puts the 'px' in the wrong place. It complicate scripts that properly
typecheck:-

if(typeof el.currentStyle.borderRightWidth == "string") {

}

If borderRightWidth were an object, as above, returning "string" would
be wrong because the object would not really be a string. It would be
legal in ES (for a Host object; value object), but "string" would be
just obviously not what the borderRightWidth is.

>  but that's abandoned for now.
>

That would seem to fulfill the third of the following three valid use cases:

1)  el.cascadedStyle - get the cascaded style of the element
2)  el.computedStyle - the style as it appears in the browser,
visually, note values like "auto" are converted, even for "clip", et c
3)  el.getComputedValueAs(property, "em") - gets the computed value,
as if the unit were specifed, and returns the number

Number (3) decouples the number from the unit, and performs a type
conversion. In most cases, the desired value is a css pixel.

The real "use case" for (3) is for hand-rolled javascript based
animations. Scenario:
 * element style property has a computed value of "16px"
 * you want to transition that over time to "17em", (a parameterized
unknown value in any unit)

I did not find the currentStyle specified in the CSSOM draft
(http://www.w3.org/TR/cssom-view/), so I googled and found:
http://dev.w3.org/csswg/cssom/
This document appears to be outdated. Please confirm. What is the correct URI?

Case (3) requires writing a function to get the font size in pixels,
then divide out to get the current would-be em value.
Element.getComputedValueAs(property, desiredUnit), would avoid this
painful and limited approach. It would open other possibilities.

Of the three possible methods, which are the most useful? This is an
open question to anyone now - post up and speak your mind. Let's hear
it.

Case (1) el.cascadedStyle - get the cascaded style

Keywords are not useful. "Inherit" is not useful.
Implementations of currentStyle sometimes return keywords or "inherit".

Why currentStyle's Keywords are Undesirable -
In IE and Opera, currentStyle return values are not clearly defined
and, in many cases, returns values that are undesirable. Such
undesirable values are "auto", "", "inherit", "medium", "bold" and
other keywords. When I get an undesirable value like "inherit", I
usually want the inherited value. For animation, it's not possible to
perform math on "inherit" -- i need a number. So I have to check the
parentNode, then the parentNode of the parentNode, all the way up
until I get a value. If the value is the keyword "red", I degrade. I
do not believe in sending down the wire a javascript colorKeyword ->
hex map. The browser should do the conversion.

Regarding "CSS Pixel" - Is this a floating point number, a floating
point number as a string with "px", a rounded number, or a rounded
number plus "px"?

What happened to the discussion of clientRight? Wow, sure got side tracked!

We still never finished the debate about offsetTop, either. We didn't
get a chance to discuss the last testcase I posted.

>
>  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...
>
http://www.w3.org/TR/REC-CSS2/cascade.html#computed-value
http://www.w3.org/TR/CSS21/cascade.html#computed-value

getComputedStyle seems to return "auto" on a lot of things.

Shorthand values don't return anything in FF. For example: -

computedStyle.margin

- is the empty string, whereas:-

getComputedStyle(document.body,'').marginTop

- is a value, e.g. "0px"

The returned value should be either 1 value or four values. Three
values requires an extra conditional check. IE will return three
values for currentStyle: -

testLogger.style.margin="12px auto 1.9em"
testLogger.currentStyle.margin

- returns the input string: "12px auto 1.9em"


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

Adding a new API creates fewer problems because the existing API can
be replaced with something that is more consistent across browsers.

clientTop being part of the web does not need specification.

If there is a use case that it fulfills and the same case could be
fulfilled with a new API, what, besides nothing, is lost?

Nothing that currently exists is broken. Nothing is lost.

Writing a specification that contradicts what implementations actually
do is unfair to web developers who use them and it is unfair to
browsers.

Consider the alternative: Create a new API based on a test suite.
The new API could have fewer problems than the existing API because it
would avoid known mistakes. It doesn't break any browsers. A new API
is easy for browsers to implement without having to worry about
breaking any existing sites -- sites that already expect a certain
different behavior.

Back to clientTop -
clientTop is useful, but only when you want a rounded pixel value, and
the element does not use left: or bottom: positioning, exists in a rtl
document. These are silly constraints but were useful when IE5 came
out.

The benefit of clientTop is that it is a number (no parsing), and it
is not a javascript function call. It's faster and simpler than
getting the computed style of the element in the defaultView and
parsing it.

Now for offsetTop: The IE5 bugs with offsetTop got mostly fixed in
IE6, but that was after Mozilla had copied the old IE5 one. The CSSOM
standard is a compromise of the old one and I don't know what. No
browser does what the spec says, and if they do change, there will be
problems with pages that use these properties. Do you care to guess
how many pages use offsetTop and offsetParent?

A new property - displacedTop - doesn't put any browser into an unfair
position. It can be implemented by every browsers without breaking any
existing sites. A new property that is simple and clearly defined. It
can be almost exactly the same as the definition of offsetTop in
CSSOM.

A test suite for the new property can help browsers with
implementation and can help developers understand these new
properties, too. Running code does not lie.

New properties don't break existing implementations.
A test suite helps everyone.

Garrett

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

Received on Monday, 10 March 2008 05:24:55 UTC