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

Re: [whatwg] WebIDL and HTML5

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 27 Aug 2008 20:12:59 -0400
Message-ID: <48B5ED8B.7080505@mit.edu>
To: Garrett Smith <dhtmlkitchen@gmail.com>
CC: Web Applications Working Group WG <public-webapps@w3.org>

Garrett Smith wrote:
> It is not compatible? Where? How?

Node.textContent.

> A spec mentioning null for a method
> that accepts a string does not make null a string.

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).

> what is "de-facto" DOM? You mean browsers? Browsers are totally
> inconsistent with each other with null.

"de-facto" in this case means existing DOM method definitions.

> That the specs talk about what happens in the event that a null slips
> doesn't change what a string is.

Please divorce the idea of DOMString and ECMAScript string in your mind. 
  They're not the same thing.

> That was a new example I posted.

Not really.  It basically showed the same default conversions as the 
other examples.

>> Right.  That discussion is what should be moved into IDL annotations.
> 
> Each method should not be moved to IDL.

I must be missing something here.  What do you mean, exactly?

> I can understand that you want to think of null as a String.

No.  I want to think of null as a DOMString.  Please see the definition 
of DOMString again.

> Null is not a string.

It's not an ECMAScript string.  It is a DOMString.

> I am capable of using string value where domstring is required.

That's great, but I don't think we should be predicating the spec on the 
restrictions you're placing on yourself.

-Boris
Received on Thursday, 28 August 2008 00:13:45 GMT

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