W3C home > Mailing lists > Public > www-style@w3.org > December 2009

Re: [cssom] Property Value API Ideas

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Wed, 2 Dec 2009 14:29:11 -0800
Message-ID: <c9e12660912021429o2cafe399ga0ee0c326aec44b@mail.gmail.com>
To: Giovanni Campagna <scampa.giovanni@gmail.com>
Cc: Anne van Kesteren <annevk@opera.com>, CSS WG <www-style@w3.org>
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.

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.

What is the other proposal?
Received on Wednesday, 2 December 2009 22:29:51 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:22 GMT