Re: [CSSOM] Can we have a .computedStyle in ElementCSSInlineStyle

> On Sat, Jul 12, 2008 at 3:15 PM, Francois Remy
> <fremycompany_pub@yahoo.fr> wrote:
>>
>>> I'm not sure I follow exactly what you'd want in runtimeStyle or
>>> currentStyle (or what the difference is).
>>
>
> currentStyle is what has been cascaded to the element, and applied.
>
> runtimeStyle is overrideStyle.

Yes, we can say it so.

>
>
>> runtimeStyle is a IE-extension that have been added to the Opera's 
>> working
>> draft about CSSOM.
>> I think it's now obsolete but I agree to explain you what it is, in fact.
>>
>> consider the following :
>>   div { display: inline; } <div style="display: none"
>> onload="this.runtimeStyle.display='block'" />
>>
>> Runtime style is a "style" attribute that overrides any other rules in 
>> the
>> document (except with !important) and which is only available by script.
>> So the DIV will be displayed as block, but div.style.display will 
>> continue
>> to say "inline" (div.runtimeStyle.display will be "block", same for the
>> readonly currentStyle).
>>
>
> Essentially, it's 'getOverrideStyle' but on the element. (not 
> defaultView).
>
> BTW - Are you parsing OK today?

What are you trying to say about "parsing" ?
I'm not very good in English, and I must acknowledge that I don't understand 
you here.

>
>> But I'm not sure it's really needed. I juste wrotten the runtimeStyle 
>> here
>> because it's already a part of the draf.
>>
>
> ?
>
> Can you elaborate on this? It sounds as if you're trying to say that
> you just wrote something about 'runtimeStyle' in a draft. Is that
> correct? If so, please provide a URI. Thanks.

Anne van Kesteren responded you in her mail.
This was the CSSOM Editor's Draft made by an Opera's member I talked about.
http://dev.w3.org/csswg/cssom/

>
>>> However, I'd note that there may be value in two different forms of
>>> specified style:
>>>
>>> * a CSSStyleDeclaration that has all properties specified in author
>>>  style sheets
>>>
>>> * a CSSStyleDeclaration that has all properties specified at all
>>>  levels of the cascade
>>>
>>> I think the first of these would be preferable for editing-type
>>> tasks (manipulating markup intended to be used later).  The second
>>> would be a little more like getComputedStyle.
>>
>
> You lost me on that one. What was it you were trying to explain?

I think he want to show the difference between currentStyle and 
computedStyle.

>
>> Consider the following :
>>   div { font-size: 200% }  <div><span style="font-size:
>> 50%">...</span></div>
>>
>> currentStyle :
>>   - on the div : 200%
>>   - on the span : 50%
>>
>> computedStyle :
>>   - on the div : 2Fpx
>>   - on the span : Fpx
>>
>
> The computedStyle would never be "2Fpx", it would have to be an
> object; one that does not have setters for style properties. The
> properties would return string values.
>
> I think you're getting at the style value for currentStyle.fontSize
> would be "Fpx" but that seems to be a mistake. What is "Fpx"?

Yes, in both of case. I give here the value of currentStyle.fontSize and 
computedStyle.fontSize

Fpx is because we don't know the size, in PX of the font.
We know the fontSize of the DIV is 2 time greater than the span's one.
But the PX-fontSize depends of the div's parent fontSize.

F is the PX-fontSize of the parent element of the DIV.

>
>>> In both cases, it would have no value for properties that aren't
>>> specified.  (This is different from computed style, which always has
>>> a value.)
>>
>
> A currentStyle should probably follow the rules of CSS, and use either
> the value given or the default value for that rule, not an empty
> string. That is what MSIE seems to do.
>
>> currentStyle should take in count the default/inherited values of 
>> property.
>>   document.body.currentStyle.fontSize should return "12pt" if it's the 
>> user
>> setting.
>>
>
> I'm not 100% sure it's the "right" way to do it, but it would be
> consistent with MSIE to return that value that is inherited (not
> return "inherit").
>

Yes, I agree.

>
>>>
>>> (Something else that might be interesting, although I'm not sure if
>>> it would be particularly useful for Web authors, is a way of getting
>>> all the author style rules that match an element.  The DOM Inspector
>>> extension to Firefox shows this information; I'm not sure if it
>>> would be useful from script.)
>>
>> Really interesting !
>> Currently, we must look at each rule and try parsing them (or in new
>> browsers, use querySelectorAll and see if the element is in the list).
>>
>> What about a IHTMLElement.appliedRules as DOMCollection(Of CSSRule) ?
>
> I like it.
>
> How about this:
>
> Have you ever tried calculating interpolated values programmatically,
> without the labor of converting between units by hand? Well then...
>
> getComputedValueAs(in DOMString propertyName, in DOMString desiredUnit)
>  computes the style value of the property, and attempts to convert
> the value to the desired unit
>
> Would provide the computation for getting a style set as "auto" to "em"
>
> This would make calculating interpolated values, between say "auto"
> and "22.39em" pretty easy. That is something that is very hard to do
> today.

You also need the reference of the element.
1em is linked to the value of the fontSize on the element (of the fontSize 
of the parent, if the em is used in the fontSize property itself)

I've done some JavaScript here that convert values in em, px, pt, ... from 
the IE's currentStyle so we can have the same result in IE as 
getComputedStyle.
It's in fact a long code. And there's currently no possibility to reconvert 
px to pt, em, ... but it seems easy to do now that we have the code.

I've added my code and a test-case in this site :
    http://www.developpez.net/forums/showthread.php?p=3474061#post3474061.

I also have posted the source (but it's not currently visible) at :
    http://www.javascriptfr.com/codes/GETCOMPUTEDSTYLE-IE-GETCOMPUTEDCSSVALUE-PT-TO-PX-EM-TO_47306.aspx

Try it and say me if it returns the same result as expected but it seems OK 
on my computer.
I followed the Opera's way to return result but there's some difference 
(default IE's value of max-width is "none" instead of "-1px")

>
> Garrett
>>
>>> -David

Fremy