W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2008

Re: [whatwg] WebIDL and HTML5

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Wed, 27 Aug 2008 22:11:25 -0700
Message-ID: <c9e12660808272211i280a70adlbc0fa957f3c79711@mail.gmail.com>
To: "Boris Zbarsky" <bzbarsky@mit.edu>
Cc: "Web Applications Working Group WG" <public-webapps@w3.org>

On Wed, Aug 27, 2008 at 5:39 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> Boris Zbarsky wrote:
>>
>> See long post with an analysis of the exact OMG IDL meaning of the
>> DOMString type (which is NOT quite the same as ECMAScript string, note).
>
> I should note that there is one thing adding to the confusion.  The use of
> String in the ECMAScript language bindings for the DOM.  If one takes this
> to mean the ECMAScript String built-in type, this is not consistent with the
> value type semantics DOMString has.

That would be true for the reason that null is not a string value.

That would also be true of the built-in String Object type.

> The inconsistency can probably be
> resolved in a number of ways, including modifying the definition of
> DOMString, declaring that the ECMAScript binding of DOMString is a String
> object (result of new String(), not a String itself),

That would seem to be inefficient.

> or declaring that a
> DOMString can be either a String or null. This last is probably the most
> backwards-compatible.

Using null where a domstring is required is not widely compatible with
existing implementations, including MSIE and Opera. In fact, you could
say it's mostly unreliable. Webkit also has strange behavior with
setting properties to null, where it can remove an attribute.

If there is a desire to handle non-string values, then that handling
should include null, which is a non-string value, both in Java and in
EcmaScript.

Garrett

>
> -Boris
>
Received on Thursday, 28 August 2008 05:12:04 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:27 GMT