Re: getComputedStyle

Joe Hewitt wrote:
> 
> I'd like to point out an interesting discussion that's been taking place on
> Mozilla's bug tracking system with regard to the DOM Level 2 method
> ViewCSS::getComputedStyle.  There are a lot of doubts in my mind, and the
> minds of others, that this method is as useful as it could be.

Joe, feel free to forward this email in the bugzilla system.
 
> http://bugzilla.mozilla.org/show_bug.cgi?id=32169
> #34500 states that there needs to be a way to get the x/y/width/height of an
> element.  However, getComputedStyle() does not guarantee to return the
> absolute pixel value for size and position.  If, for instance, an CSS had :
> "width: auto".  getComputedStyle() would then return "auto" for the width
> property, which is not is not what the reporter of bug #34500 is looking for.

In http://www.w3.org/TR/2000/CR-DOM-Level-2-20000307/css.html#CSS-ViewCSS
[[
5.2.1. Override and computed style sheet
This interface represents a CSS view. The getComputedStyle method provides a
read only access to the computed values of an element.
]]

and in http://www.w3.org/TR/1998/REC-CSS2-19980512/cascade.html#computed-value
[[
Specified values may be absolute (i.e., they are not specified relative to
another value, as in 'red' or '2mm') or relative (i.e., they are specified
relative to another value, as in 'auto', '2em', and '12%'). For absolute
values, no computation is needed to find the computed value.

Relative values, on the other hand, must be transformed into computed values:
percentages must be multiplied by a reference value (each property defines
which value that is), values with relative units (em, ex, px) must be made
absolute by multiplying with the appropriate font or pixel size, 'auto' values
must be computed by the formulas given with each property, certain keywords
('smaller', 'bolder', 'inherit') must be replaced according to their
definitions.

In most cases, elements inherit computed values. However, there are some
properties whose specified value may be inherited (e.g., the number value for
the 'line-height' property). In the cases where child elements do not inherit
the computed value, this is described in the property definition.
]]

There are three groups of values in the CSS2 specification:
- specified (also called cascaded).
  Basically, this is the result of the cascade.
  These values are not exposed in the DOM.
- computed
  All relative values are converted into computed values.
  These values are accessible through the getComputedStyle method.
- actual
  These values are really what you have on your user agent.
  They are not (yet) exposed in the DOM.
  See also
http://www.w3.org/TR/2000/WD-DOM-Requirements-20000412/#Level-3-VF-Requirements

The CSS DOM also exposed the values of the style sheets.

This issue has been raised on the DOM public mailing list one month and we
changed the description of the CSSStyleDeclaration. Here is the new one (will
be in the next release of the spec):
[[
The CSSStyleDeclaration interface represents a single CSS declaration
block. This interface may be used to determine the style properties currently
set in a block or to set style properties explicitly within the block.

While an implementation may not recognize all CSS properties within a CSS
declaration block, it is expected to provide access to all specified properties
in the style sheet through the CSSStyleDeclaration interface.  Furthermore,
implementations that support a specific level of CSS should correctly handle
CSS shorthand properties for that level. For a further discussion of shorthand
properties, see the CSS2Properties interface.

This interface is also used to provide a read-only access to the computed
values of an element. See also the ViewCSS interface.

Note: The CSS Object Model doesn't provide an access to the specified or actual
values of the CSS cascade.
]]

> For getComputedStyle() to be useful to content developers in as many
> situations as possible I'd like to (and probably soon will) make
> getComputedStyle() really return the computed style, not just what's
> immediately specified in the stylesheets since that's rarely enough, but the
> actual computed style as it is displayed on the screen (or whatever media,
> actually). The implementation will support CSSPrimitiveValue so the values
> will be accessible in a number of units (px, mm, cm, in, pt, ...) depending
> on the property.

This is the current definition of the computed style in the CSS OM. This is a
read only access.

> Just thought I'd also note that IE5's proprietary .currentStyle property does
> behave the way I'd like it to: for each property it reports the literal value
> that cascades, and doesn't attempt to compute an absolute value.  If you want
> absolute values, you have the offset* properties.

Not sure but I *think* that IE5 .runtimeStyle does behave like getComputedStyle.

> Yes, I see the evil in the offset properties, and agree it's better not to use
> them, but I think the solution I outlined above (using getPrimitiveValue and a
> unit type) is the best solution.
> 
> ------- Additional Comments From David Baron 2000-05-05 11:13 -------
> 
> Joe, and others - Would the proposal
> http://www.people.fas.harvard.edu/~dbaron/tmp/getCascadedStyle be useful to you?
> I would like to send this to www-dom, but I wanted to know if this would be
> helpful to you, and if you have any comments on it first.

Hum, this proposal is really late in the process... Don't really expect to see
your proposal in the DOM before DOM Level 3. Anyway, send your proposal in the
DOM public mailing list for the record and it will be considered for DOM Level
3.

> jst - Have you investigated how hard it would be to fully implement
> getComputedStyle()?  I would imagine it would be quite hard, since a lot of
> the needed information is all over layout, but I could be wrong.

getComputedStyle requires a layout engine, that's a fact. We decide to not make
this method optional because we think that having a complete CSS OM
implementation without a layout engine doesn't make sense.

> A few more thoughts. How does getComputedStyle know how to compute an
> "absolute" value for various unit types? How does it define what units are
> "relative"? It really SHOULDN'T know.  The developer should be able to make
> this decision.
>
> Sure, maybe "px" is absolute if you're talking about a monitor, but what if
> you're talking about a printed copy?  Then maybe you want "pt".
> getComputedStyle has no way to know what you want.
> 
> "font-size" is a good example.  If I want the computed value of "font-size:
> medium", do I want it in "em", "px", "pt", or what?  getComputedStyle doesn't
> know.  What if I want the computed value of "color: red".  Do I wanted it to
> be "red" or "#ff0000".  Again, we should use CSSPrimitiveValue to make this
> decision for ourselves.

The computed style is attached to a CSSView. This view contains information
about the layout. Currently, the CSSView doesn't expose anything in the DOM. We
made a choice between "waiting for DOM Level 3 with a complete definition of
the Views model" and "adding an abstract view now and defining this view in DOM
Level 3". So 
 
> So, my proposal to the DOM working group is as follows:
> 
> 1). rename getComputedStyle to getCascadedStyle

See my previous comment. getComputedStyle is _really_ the computed style.
 
> 2). The values in the returned CSSStyleDeclaration should not be absolute
> values, they should be whatever value has cascaded.  In the case of computed
> inherited values, the unit of the cascaded value will be the unit that the user
> agent has done the computation in.

ditto.

> 3). CSSStyleDeclaration::getPropertyValue would return the string value that
> cascaded.
>
> 4). CSSStyleDeclaration::getPropertyCSSValue would get a CSSPrimitiveValue
> interface which could then be used to convert this string into
> whatever "absolute" unit the developer may be seeking.
> [ ... ]
> I think CSSPrimitiveValue is an inappropriate place for finding computed values
> since it can occur in style rules that match multiple elements.  The conversions
> done by getFloatValue are explained better in the interface definition for
> CSSPrimitiveValue than in the definition of the method.

We use the CSSStyleDeclaration in two situations:
- to expose the values within the CSS rules.
- to expose the computed values. 
Both are exposing the string values and the CSSValue objects.

> Simple getComputedStyle should be in beta2, what this means is that only a few
> properties will be implemented.
> 
> David, I like your proposal, I agree that the computed style and the cascaded
> style should be different methods. I haven't had time to think about all the
> details involved here and I probably won't untill I land the initial support for
> this. A full implementation of getComputedStyle() is a lot of work, there's
> something like 120 different properties in CSS2 but I don't think that
> implementing any one property is really difficult but doing them all is a lot of
> work.

I understand that there is a lot of works but don't forget that :
- the CSS OM is not only for CSS2. You have to implement the CSS2 model only
  if you claim to implement the features "CSS2" or "CSS2Properties".
- Mozilla is only a screen user agent.
- some properties are not always available for all elements.

It reduces a bit your set of properties to implement for CSS2. But. are you
really going to claim the support of CSS2 for the next release of Mozilla ?

Philippe
-- 
Philippe Le Hegaret - http://www.w3.org/People/LeHegaret/
World Wide Web Consortium (W3C), DOM Activity Lead

Received on Tuesday, 9 May 2000 13:37:45 UTC