- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 27 Aug 2008 20:12:59 -0400
- 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 UTC