Bug 6141

Summary: DOMCSSPrimitiveValue is always returning values in pixels when using getComputedStyle:
Product: WebKit Reporter: Ohmson <ohmson>
Component: CSSAssignee: Beth Dakin <bdakin>
Status: RESOLVED FIXED    
Severity: Normal    
Priority: P2    
Version: 420+   
Hardware: Mac   
OS: OS X 10.4   
Attachments:
Description Flags
JS test case
none
Patch
hyatt: review+
Updated layout test none

Description Ohmson 2005-12-18 14:32:49 PST
I get a DOMCSSStyleDeclaration when using -[DOMDocument getComputedStyle::]. From the 
declaration, I can get the DOMCSSValue when using -getPropertyCSSValue. In my case, I needed to find 
the CSS 'font-size' of an element.

The object returned in getPropertyCSSValue is actually a DOMCSSPrimitiveValue object. In my CSS file, I 
actually have 'font-size: 10pt;' but when I try to use -[DOMCSSPrimitiveValue primitiveType], it is always 
returning me DOM_CSS_PX

Maybe because the values are 'computed' and so everything is in one kind of metrics, 'px'...

But at least -[DOMCSSPrimitiveValue getFloatValue:DOM_CSS_PT] should have given me back the '10.0', 
instead of '13.3333'
Comment 1 Joost de Valk (AlthA) 2006-02-17 01:44:46 PST
It's getting the computed style, the final value is always in px effectively... I'm sorry, this is a wontfix.
Comment 2 Alexey Proskuryakov 2006-02-17 13:44:46 PST
What about the final part of the report? It indeed looks strange that the specified unit type is ignored:

double getFloatValue(unsigned short /* unitType */) const { return m_value.num; }
Comment 3 Alexey Proskuryakov 2006-02-17 14:33:50 PST
Created attachment 6570 [details]
JS test case
Comment 4 Beth Dakin 2006-04-21 16:19:13 PDT
Created attachment 7887 [details]
Patch

Here is a patch that fixes the bug. I talked through this design with Hyatt. Since we use getFloatValue() internally a lot, I created another version that still just returns m_value.num since that is what the internal callers expect and since passing in the type was clunky and unnecessary. It is also worth noting that the given test case does not contain the exact value we return. The test case expects that we render floating point pixels, but we round to integers. This causes the expected calculation to be off from the actual calculation. (It also means that our results, while accurate, do not match Firefox exactly.) I will upload a more accurate test in a minute.
Comment 5 Beth Dakin 2006-04-21 16:21:09 PDT
Created attachment 7888 [details]
Updated layout test
Comment 6 Dave Hyatt 2006-04-21 22:01:14 PDT
Comment on attachment 7887 [details]
Patch

r=me
Comment 7 Beth Dakin 2006-04-22 12:23:37 PDT
I committed the patch.