- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Sat, 2 Jan 2010 22:50:02 -0800
- To: Giovanni Campagna <scampa.giovanni@gmail.com>
- Cc: Patrick Garies <pgaries@fastmail.us>, Travis Leithead <travil@microsoft.com>, www-style <www-style@w3.org>
Was this unclear or confusing? Does Microsoft intend to provide an API to read styles for IE9? On Tue, Dec 22, 2009 at 12:57 PM, Garrett Smith <dhtmlkitchen@gmail.com> wrote: > On Tue, Dec 22, 2009 at 4:53 AM, Giovanni Campagna > <scampa.giovanni@gmail.com> wrote: >> On Tue, Dec 22, 2009 at 10:30 AM, Patrick Garies <pgaries@fastmail.us> wrote: >>> On 9/22/2009 8:08 PM, Garrett Smith wrote: >>>>> >>>>> I also assume that getStyleAs can return a plethora of possible values >>>>> from strings to other interfaces... >>>>> >>>> >>>> I was thinking it would return a string although |asNumber| param >>>> might a possibility:- >>>> >>>> x.getStyleAs("length", "px", "number"); >>>> >>>> Returns a number representing the length, in css pixels. >>> > > Ah, no, there is no "length" /property/. > > How about "width" for an element. > > // Read el's computed width, in px, but as a number. > el.getStyleAs("width", "px", "number"); > > On second glance, the method returning either string or number is > complex and inconsistent. The extra - valueType - argument is > responsible for this problem. It should be omitted and the method > should return a string. And so that leaves: > > el.getStyleAs("width", "px") > > - which is already complicated enough. > > This fulfills the goal of reading a computed style. > > This does not allow for reading/parsing of numbers, nor does it allow > for value object. > >>> For some reason, I'm thinking Travis was wondering what all the types of >>> returnable values are. So far, pixels, integers, and RGBA seem to be covered >>> based upon your examples. |rgb| is also mentioned, but it's not clear if >>> that's a reference to the hexadecimal or functional notation. >>> > > The string "rgb" would get an RGB functional notation string > > el.getStyleAs("color", "rgb"); > => "rgb(0, 0, 0)"; > > el.getStyleAs("color", "rgba"); > => "rgba(0,0,0,1)" > > el.getStyleAs("color", "#"); > => "#000000" > > Other situations will want an Object or number: getStyleObject, getStyleNumber. > > var c = el.getStyleObject("color", "rgb"); > [c.r, c.g, c.b] + ""; > => "0, 0, 0" > > And for the number case, something like: > > var c = el.getStyleNumber("color", "rgb"); > => 0 > > The idea of style.width.px++ wont be compatible with the web today and > 2++ would be an error. However, parts of the idea could be used for a > different object. > > Another proposal to read computedStyle on an HTMLElement that is not > disconnected, call it "ElementComputedStyle". Example: > > el.computedStyle.color+ "" > => "inherit"; > > el.computedStyle.color.rgb.r > => 0 > > el.computedStyle.width.r > => undefined > > As you can see, the object returned from the css property name varies. > If it is a css length type of property, the object will have a - px - > property. If it is a CSS Color object, it will have an - r- property. > > A setter for the computedStyle object would not make sense because it > is a *computed* style. > > For setting values on an element, the element's style object could be > used. Example: > > el.style.width = el.computedStyle.width.percent + "%"; > > Finally, a third idea is "LiveStyle". > > LiveStyle mixes computedStyle (for getting), overrideStyle (for > setting), and cascaded style, for default value in toString, into one > object. The object would have a toString function that returns the > *cascaded* style. The LiveStyle interface implements CSS2Properties, > but each CSS2Property of a LiveStyle has a new DynamicStyle properties > that implements CSS2Properties > > interface LiveStyle : CSS2Properties { > string toString() > } > > Interface DynamicStyle : CSSStyleDeclaration { > string toString() > long valueOf() > } > > The properties for a DynamicStyle depend on the property in question. > For RGBColor, an - r - property would be present, but for width, no r > property would be present. For property values that read a > computedStyle and set an overrideStyle. The liveStyle value itself > serializes the cascaded style. > > el.liveStyle + ""; > => "color: red; width: auto" > > el.liveStyle.width + ""; // cascaded style, as declared. > "auto"; > > el.liveStyle.width.px; // computed style, in px > => 10 > > el.liveStyle.width.px++; // Read computedStyle in px, add 1, and set > override Style, in px > => 11 > > el.liveStyle.color; > => "inherit" > > el.liveStyle.color.r += 10; > => 255 > > Shorthand properties such as margin, pading, borderWidth, etc add > complexity with multiple CSS value types for both proposals. The > complexity of shorthand properties have to be considered to either > ignore, or consider handling iff is the property takes a length and > all values are equal. > > // Shorthand, but risky. > el.style.margin = el.computedStyle.margin + "px"; > > There are the three proposals. > 1) getStyleAs - reads a computed style, returns a string > 2) ElementComputedStyle - reads computed style from non-disconnected element. > 3) LiveStyle reads cascade style, computed style, sets override style. > > Aside from it would be useful to have a standard specify conversion of > ToString for the setter of style property. So that setting a style > property to an object would result in calling the internal ToString > for the assigned value. > > // Assign a string value. > el.style.width = "10px"; Standard. > > // Proposed: > // Leverage ECMAScript internal [[ToString]] > anotherEl.style.width = { toString: function(){ return "10px"; }}; > > Garrett >
Received on Sunday, 3 January 2010 06:50:35 UTC