Loading ...
Sorry, an error occurred while loading the content.

Re: [ydn-javascript] Dom.getStyle problems

Expand Messages
  • Matt Sweeney
    Hi Ryan, The rationale behind having wrappers for the style interface (Dom.setStyle, Dom.getStyle) is because getting the initial style values can be
    Message 1 of 2 , Jul 5, 2006
    • 0 Attachment
      Hi Ryan,

      The rationale behind having wrappers for the style interface
      (Dom.setStyle, Dom.getStyle) is because getting the initial style values
      can be difficult. When a style is set via the "style" property
      (element.style.width = '20em'), the style property always returns the
      actual value. The same goes for styles set inline (<div
      style="width:10em"...). However, if a style is not set via either
      "element.style" or "<element style=...", an empty string is returned.

      Our only choice at this point is to either parse the stylesheet or get
      using some other method(s). Parsing the stylesheet has performance
      limitations, so we really can only rely on other methods; namely
      currentStyle and computedStyle.

      CurrentStyle enables embedded or linked/imported styles to be queried in
      the same fashion (what you set is what you get, regardless of setter
      interface). As you point out, one downside is that it does not compute
      values for unset style properties the way that computedStyle does, and
      returns 'auto' in some cases. This also introduces browser
      inconsistencies which may require some additional work to resolve.

      ComputedStyle returns the computed value that the browser uses to render
      the style. Although this may be helpful in some cases, I would argue
      that it is not really what we want from getStyle.

      Opera 9 has complicated this by adding support for currentStyle, but
      unlike IE, it returns computed values rather than actual values. Also,
      as your example demonstrates, when the "height" property is not set,
      Opera returns "-2147483648px" rather than "auto".

      I agree that we should protect against this by ensuring that Opera
      always return computedStyle. However, if Opera 9 emulated IE by
      returning the actual style values regardless of setter interface, I
      would argue in favor of continuing to check currentStyle first.

      Thanks for bringing this up.

      Matt

      Ryan Cannon wrote:

      >Greetings,
      >
      >I've searched through the archives a little bit, and haven't found
      >much, but I've had a difficult time getting around problems with the
      >Dom.getStyle function. Specifically, el.currentStyle and
      >document.defaultView.getComputedStyle *do not* return the same kinds
      >of values when some properties are not explicitly set[1]. Right now
      >I'm working on a patch/workaround for my own site, but I do have one
      >question.
      >
      >When I grok the code for Dom.getStyle, it appears the script does the
      >following:
      >
      >check if node.style[property] exists, and uses it if it does;
      >that failing, it looks for node.currentStyle[property] (IE DOM
      >extension);
      >that failing, it looks for document.defaultView.getComputedStyle
      >(node) (W3C DOM)
      >
      >Why is the non-standard DOM extension checked first? It supplies
      >difficult-to-parse
      >values, such as 'auto'. Browsers that support both functions (Opera,
      >hopefully IE7)
      >have the ability to avoid these headaches (and the extra cycles to
      >get around them)
      >but don't because of the order in which they are checked.
      >
      >[1]: http://ryancannon.com/bugs/yui/getStyle/
      >
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.