Re: [cssom] Property Value API Ideas

On Mon, 30 Nov 2009 22:00:10 +0100, Garrett Smith <dhtmlkitchen@gmail.com>  
wrote:
> On Mon, Nov 30, 2009 at 12:52 AM, Anne van Kesteren <annevk@opera.com>  
> wrote:
> It is important to state the problem that a proposed solution is
> intended to solve before proposing solutions.

Right, the email I pointed to had some analysis of that.


> Problem, in a nutshell, is:
> Reading element style is a painful task for cross browser code.
>
> A javascript library should not be needed for that.
>
> Sound right?

I think scripted transitions/animations are an important consideration  
too. In particular the ability to skip string manipulation.


>> During TPAC some members of the CSS WG and people outside the CSS WG
>> discussed the idea of a potential replacement for CSSValue. Inspiration  
>> came
>> from a very old proposal by Ian Hickson which was originally  
>> Member-only but
>> I've since made available publicly here:
>>
>>  http://lists.w3.org/Archives/Public/www-archive/2009Nov/0007.html
>
> I see two proposals there:
> 1) element.computedStyle
> 2) A munged data type, as you mention here
>
> An element.computedStyle, if imporved to element.absoluteStyle, would
> be easy to use, useful, implies guaranteed *absolute* style units, and
> is easy to feature test.
>
> A munged data type, as you mention here, has serious detrimental
> conseqences. For one, it creates a new data type for ECMAScript; not
> string; not object. This requires additional handling for typeof
> operator.

That depends on how we do it exactly. I agree that we probably do not want  
a new ECMAScript data type.


>> The idea is to make the members of CSSStyleDeclaration return a mix  
>> between DOMString and a real Object.
>
> A consequences of such design is that it breaks feature detection, as
> explained here:
> http://lists.w3.org/Archives/Public/www-style/2009Oct/0061.html

I could not find an explanation in that email but I do not see why you  
would not be able to do e.g.

   if("cssText" in obj.style.width)

assuming cssText will be a member of the new value interface.


>> This would mean that e.g. triple-equality
>> checks would no longer work and hopefully nobody relies on those  
>> specifics
>> but if they do we have to think of something else. (Suggestions for  
>> "else"
>> that floated around were having a new member on CSSStyleDeclaration that
>> gives a CSSImprovedStyleDeclaration, having a new member for each CSS
>> property, etc.)
>
> Creating a new Data type that behaves in an incompatible manner with
> ECMAScript is a bad idea.

I don't think I suggested that.

Essentially the new object would inherit from DOMString and implement the  
same members. At least one of the members of TC39 thought it was  
plausible, but it requires further study.


> Google Code Search for code patterns that expect style properties to
> be string value:
>
> typeof x.style
>
> That is a common and obvious way to feature test style properties.
>
> A google code search for:
>
> typeof\s+(\w+\.)style[\[\.] lang:javascript
>
> - resulted in about 2000 hits.
>
> http://www.google.com/codesearch?hl=en&lr=&q=typeof%5Cs%2B%28%5Cw%2B%5C.%29style%5B%5C%5B%5C.%5D+lang%3Ajavascript&sbtn=Search

It does not seem like a lot of these would break, but yeah we need to test  
for compatibility obviously.


> Those programs should continue to function. Those programs should be
> checking against "undefined", but that is beside the point. (An
> implementation might use null instead of empty string for unset, but
> present properties.
>
> Creating a new data type that is incompatible with ECMA-262 (no string
> value with properties) adds too much complexity.
>
> How about an alternative to allow the developer to choose object, such  
> as:
>
>   style.getValue(prop)[ unit ]
>
> A program could use:
>
>   document.body.style.getValue("width").px;
>
> For non-dynamic language, a corresponding method:
>
>   document.body.style.getValue("width").valueTypes.get("px");
>
> That seems to fulfill your use patterns. It won't break any existing
> code. Feature testing the getValue method should not be a problem.

Yes, see my original email for similar alternatives.


> A comprehensive test suite would help to get better perspective on
> edge cases, such as trying to read hsla, background color, shorthand
> values.
>
> Another proposed idea was document.defaultView.getAbsoluteStyle.

Yeah, when the better definitions of old material are much more stable I'm  
planning on going through the list of requested features.


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Wednesday, 2 December 2009 16:12:25 UTC