W3C home > Mailing lists > Public > www-style@w3.org > July 2008

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

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Sat, 12 Jul 2008 16:06:42 -0700
Message-ID: <c9e12660807121606m536d7b3dj92ac2f10bda71ec@mail.gmail.com>
To: "Francois Remy" <fremycompany_pub@yahoo.fr>
Cc: "L. David Baron" <dbaron@dbaron.org>, "CSS 3 W3C Group" <www-style@w3.org>

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.


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


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


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

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


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



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

Garrett
>
>> -David
Received on Saturday, 12 July 2008 23:07:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:10 GMT