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: Sun, 13 Jul 2008 11:54:01 -0700
Message-ID: <c9e12660807131154v401af0c0o9c828a7f34ed3e98@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 Sun, Jul 13, 2008 at 2:54 AM, Francois Remy
<fremycompany_pub@yahoo.fr> wrote:
>> 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.

There was previous mention somewhere of difficulty parsing my mail.

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

I see.

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

I think he may have been trying to communicate something regarding
weight of rules with user preferences. ComputeStyle would take user
preference into account for something like: font-size: 200%. IAC It
needs more explaining. David (or is it "L"?) can you please elaborate
on this?

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

I think that the "no value" part is not correct. I think that when
currentStyle doesn't have a value found in the cascade, then "initial
value" should be used. It seems that MSIE does return the "initial
value" for current style (at least in most cases).

For example, consider the classic problem of finding the border width
of the root. MSIE will return "medium" for currentStyle. MSIE will
return "medium", which is the "initial value" of the "border-width",
specified by CSS2 (CSS 2.1 here).

| border-top-width', 'border-right-width', 'border-bottom-width',
|  'border-left-width'
|    Value:  	<border-width> | inherit
|    Initial:  	medium
|    Applies to:  	all elements
|    Inherited:  	no
|    Percentages:  	N/A
|    Media:  	visual
|    Computed value:  	absolute length; '0' if the border style is
'none' or 'hidden'

Where the computed value of the width might be "0", MSIE can report
"medium" for currentStyle.borderTopWidth and "none" for


If currentStyle returns "no value" (or the empty string), then it
would work differently than MSIE, which seems to return the "initial
value" in most cases.

MSIE provides the 'clientTop' and 'clientLeft' (but not 'clientBottom'
or 'clientRight').

Ideas discussed:-

 el.getCascadedRules()  ("L David" idea, returns cascaded rules
applied to element (method signature TBD))
 style.getComputedValueAs(propertyName, desiredUnit)  (Garrett's idea,
returns value in desiredUnit)

All of these seem useful to me.


>> Garrett
>>>> -David
> Fremy
Received on Sunday, 13 July 2008 18:54:40 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:38 UTC