Re: Fwd: cssom - clientTop, et v

Garrett Smith wrote:
> Anne van Kesteren wrote:
>> Garrett Smith wrote:
>>> Element.getComputedValueAs(property, desiredUnit), would avoid this
>>> painful and limited approach. It would open other possibilities.
>>
>> How does that work for properties that don't take units, but keywords?  
>> Or properties that take <color> values?
>
> null. or empty string. null could mean "not supported". If the method
> returns empty string, it might be a likely bug. I say this because
> some browsers still return empty string for some valid css 1
> propertyValues on a computed style.
>
> For color, well, I guess you could allow for ("rgb" or "#") - that
> might be useful.

Given the variety of values CSS properties take (and still expanding) I'm  
not sure if your proposed method really scales. Having interfaces for  
properties would probably work better. Then again, this would be something  
for v2.


>>  That sounds reasonable. I've added a note about cascadedStyle.
>
> That's not showing up here: http://dev.w3.org/csswg/cssom/

Sorry, meant comment. And also, it's not checked in yet.


>>> 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"?
>>
>>  A CSS pixel is a CSS pixel. The representation depends on the context.
>
> I'm trying to understand if includes a decimal point or not. Can you
> define CSS pixel?

As I said, depends on the context. CSS pixels are defined by CSS:

   http://www.w3.org/TR/CSS21/syndata.html#length-units


> My point about clientTop (the one you snipped) described that
> clientTop is a rounded number, where as currentStyle is a string value
> that includes units. This string value is not rounded, well in Opera
> it is often floored, but that is a bug.

I don't get the point. Yes, clientTop is an integer, and yes, the computed  
style serialized as string can include more precision. Is that your point?


> Correct. For a period of time, perhaps 2 years, browsers support both.
> Scripts will also have to support both.

A lot longer than two years. In fact, this assumes that all pages will be  
updated.


> Problems of a new API can be significantly reduced with a test suite.
> Not a post-hoc, ad-hoc acid test, but a conformance test before the
> fact, to actually prevent problems.
>
> I asked "Do you care to guess how many pages use offsetTop and  
> offsetParent?"
>
> Should I assume your answer is "no"?

People have done surveys (not published) over several million pages to  
find out. I forgot the details, but enough pages do it for it to matter.


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

Received on Monday, 10 March 2008 10:22:34 UTC