Re: [cssom] Property Value API Ideas

2009/12/2 Garrett Smith <dhtmlkitchen@gmail.com>:
> On Wed, Dec 2, 2009 at 11:57 AM, Giovanni Campagna
> <scampa.giovanni@gmail.com> wrote:
>> 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:
>
> [snip]
>
>>>>> 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 equality operator does not need to be overloaded.
>
> The equality operator does value comparison when one operand is value
> and the other is an object
>
> "0" == ({valueOf:function(){return "0";}}); // true
>
> So all that would be necessary to compare object to string is to give
> the object a toString and/or valueOf. Those methods work great for
> value object.

Good. I thought only of Object("a") != Object("a"), but those are not
needed (who compares the values of two different properties?)

>
> DOMStrings are string value in ECMAScript. That is not going to
> change. DOMString will still be string value.
>
> style.width is a string value and must continue to be. The proposal to
> change style.width from string value to Object would break most
> applications. It would also introduce a lot of complexity that would
> need specifying (like what happens when a DOMString is expected but a
> non-domstring is used, or how to program interoperable programs using
> old DOMString and new DOMString.

Exactly, what are the incompatibilities, except typeof and ===?
Specifying the "style.width" setter is already needed (since it has to
update the underlying style, the style attribute, throw for parse
errors, etc.), adding support for both string and CSSStringlikeValue
is not that problem.
If you want to write interoperable programs, use String() for
accessing, or use typeof for feature detection.

> What is the other proposal?
>

I think extending the existing CSSValue, making it more settable
(currently only lengths / times / angles are), while keeping the
getPropertyCSSValue() method. This would mean:
style.getPropertyCSSValue("width").px

Better still would be like: style.defaultAccessor = CSS_TEXT and
style.defaultAccessor = CSS_VALUE, deciding what style.width returns
on getting. Values and strings can be accessed anyway with
style.getPropertyValue and style.getPropertyCSSValue

Giovanni

Received on Thursday, 3 December 2009 13:53:30 UTC