- From: Leif Arne Storset <lstorset@opera.com>
- Date: Fri, 12 Jul 2013 17:30:41 +0200
- To: www-style@w3.org
- Cc: mail@rodneyrehm.de
Rodney Rehm tried unsuccessfully to post to this list, and put the following on Tab's blog [1] in response to the .specifiedStyle proposal. -Leif -- Original message -- As a library author I want to identify longhand / shorthand properties. This is required so I can ignore margin in favor of margin-left et al. Right now this would be handy because we only have computedStyle, an returned values for shorthands vary across browsers. Even if there is a way to retrieve a proper value for a shorthand, this type information is still useful. I could use this in a rendering of the CSSOM (a la Dev Tools), ´prevent processing shorthands if there are (simpler to parse) longhands, etc. As a polyfill author I want to know about unsupported properties. Tab made the argument that you could use custom var- properties for that, but that would require the CSS author to provide (unnecessary) duplicate definition. I wouldn't want this exposed as a regular property, rather accessible through a separate list from CSSStyleDeclaration. (We will always be "fixing" stuff for older browsers) As a library/polyfill author I want to know the type(s) a CSS property accepts. This is static data. It allows me to control different parsing / serialisation modes when processing property values. A map like this probably already exists within implementations (for pretty much the same reason). There are various serialized presentations of values. Colors (HSLa, RGBa, HEX, keywords) are a great example of how we have to parse strings in javascript-land simply so we can do some funky calculations on them. List-properties (such as animation-*, transition-*, box-shadow) require manual splitting. Way more "stupid string wrangling" than should really be necessary - considering engines already perform these tasks internally. I don't want to have to throw kilobytes of javascript at simple and repetitive problems like this. In a first step these complex value types should expose their components (RGBA: red, green, blue, alpha). In a second step these value objects could be enriched with utility functions such as lighten(<percentage>) for colors. [1] http://www.xanthir.com/b4Qi0#4Qi0-14
Received on Friday, 12 July 2013 15:31:29 UTC