- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Wed, 2 Dec 2009 14:29:11 -0800
- 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 UTC