Garrett Smith wrote:
So is everything else. This particular desire has great benefits, however,
so it needs to have great drawbacks as well to not be done, right?
The drawback would be inconsistency with current implementations
How so? Anything that specifies interoperable behavior would have this
problem in some cases, as testing indicates. In cases when the behavior
is already interoperable there is no inconsistency.
and with the behavior that developers might naturally expect.
That's an issue even if it's just the spec text that says that null is
treated in a special way.
Again, what is your specific problem with the specific approach of
annotating null/undefined conversions as opposed to just describing them
in the spec text?
I disagree. That the DOM spec does not include null. It is very
verbose on what it does include, so it's not by accident.
Then how do you account for all the places in the same spec that talk
about passing null to DOMString arguments?
I believe that null should be handled based on what it is.
That's fine. How is it compatible with the existing specs?
Yes, because de-facto DOM does this already.
My examples clearly show otherwise. null is handled differently in
Firefox, [Opera/IE], Safari, depending on what DOM method /property it
is used for.
I don't see what that has to do with my statement above, that de-facto
DOM method specifications assume that null can be passed for a DOMString
and that a number of DOM methods specify what should be done in that case.
Honestly, you can stop copy/pasting the same examples in. We've seen them.
That is true. There are methods that discuss what happens when you
pass null to a method that accepts a domstring.
Right. That discussion is what should be moved into IDL annotations.
-Boris
