getComputedStyle vs. getCascadedStyle

[ I sent this message to www-dom this morning, but it didn't get through.
Apologies in advance if anyone gets two copies.  I think the copy I sent
this morning had a few additional revisions, but I'm not sure. ]


The getComputedStyle method of the ViewCSS interface [1] is somewhat
difficult to implement because it requires the computed values, which
in some implementations are handled to some degree outside the style
system.  I propose below an additional method (for the DocumentCSS
interface [2]) that could offer much of the same functionality and
would be easier to implement.  Below that, I will comment on what I see
as the biggest problem with getComputedStyle.


This proposal for getCascadedStyle is, I think, more similar to IE5's
currentStyle property [3] than getComputedStyle is.  It would allow the
retrieval of the cascaded style for an element, which is often what the
user wants (or, if it is "inherit", it could be figured out for some
properties by walking up the tree until a non-inherit value is found):

  Interface DocumentCSS
  Method getCascadedStyle
  Parameters:
    Element elt  [ same as getComputedStyle [1] ]
    DOMString pseudoElt  [ same as getComputedStyle [1] ]
  Return Value:
    CSSStyleDeclaration  The cascaded style for the element.  The
      CSSStyleDeclaration is read-only, and contains the cascaded
      values for the element.  If no rule matching the element and
      pseudo-element contains a declaration for a property, the value
      for that property should be the default value of that property
      (if it is not inherited) or the value "inherit".


I also have one rather serious objection to getComputedStyle.  It
requires that the computed styles be returned in absolute units.  This
means they should be returned in "pt", "in", or "mm" (etc.), and not
"px".  Conversions to pixels are explicitly forbidden in the definition
of CSSPrimitiveValue [4].  This will mean that authors will be
encouraged to use absolute measurements for screen media, where such
measurements are unreliable due to platform differences.  This practice
leads authors to make web pages that are geared toward one platform
(generally Windows, with its large default logical resolution) and that
are illegible on other platforms.  (Try reading [3] on a machine with a
logical resolution of 75ppi.)  It is also explicitly discouraged by the
CSS specification [5].  If DOM implementations return values in these
units, it will encourage authors to think in and use absolute units,
which promote incompatibility within the screen medium.

-David

[1] http://www.w3.org/TR/DOM-Level-2/css.html#CSS-ViewCSS
[2] http://www.w3.org/TR/DOM-Level-2/css.html#CSS-DocumentCSS
[3] http://msdn.microsoft.com/workshop/author/dhtml/reference/objects/currentStyle.asp
[4] http://www.w3.org/TR/DOM-Level-2/css.html#CSS-CSSPrimitiveValue
[5] http://www.w3.org/TR/REC-CSS2/syndata.html#length-units says:
    "Absolute length units are only useful when the physical properties
    of the output medium are known."

L. David Baron    Sophomore, Harvard (Physics)    dbaron@fas.harvard.edu
Links, SatPix, CSS, etc.     <URL: http://www.fas.harvard.edu/~dbaron/ >
WSP CSS AC                      <URL: http://www.webstandards.org/css/ >

Received on Tuesday, 9 May 2000 16:49:50 UTC