On Wed, 27 Aug 2008 08:34:03 -0400, Boris Zbarsky <[EMAIL PROTECTED]> wrote:
Michael A. Puls II wrote:
'textContent' takes a DOMString, null is not one
Uh... Except null IS a DOMString according to the DOM specs. Certainly
they implicitly treat it as one, and one of the clarifications that
WebIDL is making is making it clearer that null is a valid DOMString
value.
null is toString()ed to "null" and the textContent becomes "null".
Except that's not what the spec for textContent says to do. Please do
read the spec. Carefully.
Yes, understood. Those were just my guesses for reasons why Opera does
what it does.
I know Opera differs in these cases compared to Safari and Firefox, but
from an ECMAScript point of view, Opera does what I expect.
But it doesn't do what the DOM spec says to do in the textContent case.
Sad, but there you are.
Understood.
With that said, if that's a behavior of ECMAScript and the DOM spec
clashes, which one gets priority and in what situations and why?
The DOM spec gets priority for methods it defines, just like in all
cases of host objects and methods. There are no requirements for those
to follow all sorts of rules that native methods and objects have to
follow. See the ECMAScript spec.
O.K. Thanks. That clears it up right there.
Although I understand why it might be desired to have null have the
same effect as "", it seems odd to be so inconsistent across different
things in the DOM and inconsistent with ECMAScript (which exposes the
DOM to users, in browsers).
It _is_ odd. But it's an established fact of life, and changing that
behavior is not acceptable at this point.
Understood.
Too bad no one brought all this up back when the DOM specs were being
written. Or maybe they did, and the non-ECMAScript users of the DOM
carried the day on the issue. Again, in other languages the fact that
null is a string is much more natural than in ECMAScript.
Yes, too bad.
Thanks
--
Michael
