On Tue, 26 Aug 2008 23:20:16 -0400, Boris Zbarsky <[EMAIL PROTECTED]> wrote:
Garrett Smith wrote:
I have created a demo which expects that setting textContent to null
will have no effect, as per DOM Core 3.
Except that's not what DOM Core 3 says. Please do read what it says.
Carefully:
On setting, any possible children this node may have are removed
and, if it the new string is not empty or null, replaced by a
single Text node containing the string this attribute is set to.
So. On setting all children are removed. If the string is not empty or
null, they are then replaced by a single Text node, etc. If it's empty
or null, the kids are removed and that's it. It would perhaps help to
write this out as a step-by-step list instead of having a moderately
complex grammatical structure with a subordinate clause, but the meaning
is still the same.
As for your test, sounds to me like Firefox and Webkit implement what
the spec says, and Opera is just buggy here.
Couple examples:
Example 1:
var div = document.createElement("div");
div.textContent = null;
'textContent' takes a DOMString, null is not one, null is toString()ed to
"null" and the textContent becomes "null".
Example 2:
var div = document.getElementsByTagName("div")[0];
div.style.display = "none";
div.style.display = null;
'display' takes a DOMString, null is not one, null is toString()ed to
"null" and since "null" is not a valid value for the display property, the
new declaration is ignored and the display remains at 'none'.
I know Opera differs in these cases compared to Safari and Firefox, but
from an ECMAScript point of view, Opera does what I expect.
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?
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'd be nice if the behavior was the same for all DOM things taking a
DOMString. But, since that probably can't happen because of compatibility,
I guess it would be great to have a way to show each and every special
case so browsers don't differ and break pages.
--
Michael
