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
