Re: [cssom] Property Value API Ideas

2009/12/2 Garrett Smith <dhtmlkitchen@gmail.com>:
> On Wed, Dec 2, 2009 at 8:11 AM, Anne van Kesteren <annevk@opera.com> wrote:F
>> 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.
>>
>
> OK. I can see some benefit in code clarity and performance by
> replacing - parseInt( val )||0) - with just - val -.
>
>>
>>>> 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.
>>
>
> You wrote:
>
> | The idea is to make the members of CSSStyleDeclaration return a mix
> between DOMString and a real Object.
>
> If the mixed object is not a new data type, I don't know what it is.

An object inheriting from DOMString (that is, bearing the standard
String prototype), but using operator overloading to get away with
"==". Maybe a value type, if such concept is introduced into ES before
operators.

>>
>>>> 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)
>
> I do want to throw a TypeError.

Do you think it is useful / necessary?
What about ("cssText" in Object(obj.style.width))

>>
>> assuming cssText will be a member of the new value interface.
>>
>
> Changing the value type of style properties, such as style.width,
> would break the web.

We should list all the assumptions a standard developer makes about
those properties and see if they can be worked around. I believe it
won't be long, given that you cannot even assume a property exists,
let alone parsing behavior or value normalization.

>>
>>>> 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.
>>
>
> A string value is not an object; it is a primitive value. A primitive
> value cannot have any properties.

In various places primitives are automatically coerced to objects
(when possible), including property access.
On the other hand, it is true that setting those properties has no
effect, since a new object is created every time.

> The in operator throws TypeError when the rhs operand is a not an object.
>
>>
>>> Google Code Search for code patterns that expect style properties to
>>> be string value:
>
> [snip]
>
>> It does not seem like a lot of these would break, but yeah we need to test
>> for compatibility obviously.
>>
>
> Changing style properties from string value to Object creates a
> temporal mixed environment where in some implementations, a style
> property will be a string value and in others it will be an Object.
>
> If this API design is implemented in a browser, a program tested in
> that browser might perform operations on the Object that would
> otherwise fail in implementations where the property value was a
> string value.

Depends on what operations you do. And you still have typeof for feature test.

> [snip]
>
>>>
>>> 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.
>>
>
> Rereading, I do not see such alternatives in the first message you posted.
>
> [snip]
>
> Garrett
>
>

Giovanni

Received on Wednesday, 2 December 2009 19:58:37 UTC