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

Dom.getStyle problems

Expand Messages
  • Ryan Cannon
    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
    Message 1 of 2 , Jun 30, 2006
    • 0 Attachment
      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/
      --
      Ryan Cannon

      Interactive Developer
      MSI Student, School of Information
      University of Michigan
      http://RyanCannon.com
    • 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 2 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.