RE: [cssom] Proposal for obtaining robust style information via Javascript - getStyle()

Hi,

Actually the information you want to get is the cascaded value of a property. This value is accessible (with some caveats) in IE via the 'currentStyle' property of an element.

   element.currentStyle.marginLeft == "auto"

This is not the first time this issue is brought to this mailling list (search for 'currentStyle' in the archives). The last time, it seems like the favored approach would have been

   element.getStyle(

      DOMString
        'property-name'

      optional DOMString
         '::pseudo-element'

      optional DOMString
        | 'used'
        | 'computed'
        | 'cascaded'
        | 'specified'
        | ...

   )

However, I don't think the discussion continued forward. I agree this is an issue, as is anything which is done by the browser and not harnessable by the scripting (now, the best option you have will be to reperform the matching/cascading yourself, and I guess this is what devtools are doing).

François



________________________________
> From: mike.sherov@gmail.com 
> Date: Sun, 27 Jan 2013 16:20:31 -0500 
> To: www-style@w3.org 
> Subject: [cssom] Proposal for obtaining robust style information via 
> Javascript - getStyle() 
> 
> Forgive my ignorance on the subject, and please correct me where I'm 
> wrong or missing information or where something exists that does these 
> things already... 
> 
> The web development community at large currently seems to be beholden 
> to getComputedStyle() as the only source of information of what styles 
> are applied to an element. The resulting CSSStyleDeclaration seems to 
> represent a significant loss of information by presenting only the 
> "resolved values" of the styles. 
> 
> For example, consider the following html: 
> <style> 
> div { margin: auto; } 
> .inner { width: 50px; } 
> .outer { width: 100px; } 
> </style> 
> <div class="outer"><div class="inner"> hi </div></div> 
> 
> In this example, using getComputedStyle() on the inner element will 
> yield marginLeft = 25 and marginRight = 25. That's good in some cases. 
> In fact, I've argued for this exact behavior before, because it's 
> usually preferable to know the used value. However there are use cases 
> where being able to detect that the specified value is "auto" is a win. 
> 
> For example, consider this jQuery UI 
> bug: http://bugs.jqueryui.com/ticket/7772 
> In this case, I would want to know that "right" was specified, and that 
> "left" was not, so that when I want to drag the element and change it's 
> apparent position, I can modify "right" instead of "left". But if 
> percents were specified, I'd want to know pixels so I can set the exact 
> pixel value upon drag instead of having to do the math myself.... so 
> I'd want used value, but only if the specified value exists! 
> 
> In general, it seems as if this one view, getComputedStyle(), can't 
> tell me enough information to accomodate everything I want to know. 
> Now, I'm no spec writer, but in a perfect world I'd want: 
> 
> window.getStyle(valueType, element[, psuedoElement]); 
> 
> and separately a new parameter on CSSStyleDeclaration.getPropertyValue: 
> 
> CSSStyleDeclaration.getPropertyValue( propertyName[, unit, valueType]); 
> 
> This would allow me to query any of the values I'd like: 
> "default","initial","specified","computed","used","actual", and 
> "resolved". getComputedStyle(elem) would be equivalent to 
> getStyle("resolved", elem). I'd also now be able to convert units or 
> value type if I wanted, simply by specifiying it as the second and 
> third parameter to getPropertyValue! 
> 
> For my above example, to get back marginRIght:auto, and then see the 
> used value is 25px, I can do this: 
> 
> var styles = window.getStyle("specified", elem); 
> console.log(styles.marginRight); 
> console.log(styles.getPropertyValue("marginRight", "px", "used"); 
> 
> If incompatible valueTypes and units are combined, an error can be thrown. 
> 
> Thoughts? 
> 
> -- 
> Mike Sherov 
> Lead Developer 
> SNAP Interactive, Inc. 
> Ticker: STVI

Received on Sunday, 27 January 2013 23:01:46 UTC