- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Wed, 27 Aug 2008 22:11:25 -0700
- 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 UTC