Garrett Smith wrote:
2) It violates the DOM Level 3 Core specification, which says: "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." Thus, clearly assigning null to
textContent must remove all children of the node.
<http://www.w3.org/TR/DOM-Level-3-Core/core.html#Node3-textContent>
In fact your option (c) appears to be mandated by the spec. Can you explain
why you stated that it is "wrong"?
No, option (c) is not mandated by the spec. That is clearly not true.
I'm a little confused here. The spec in question clearly requires that
for this method "" and null be treated identically. So what's "clearly
not true", exactly?
I don't agree that that is a good way to handle null, but it is clear
that these two:
document.body.textContent=null;
document.body.textContent='';
Are specified as being different from each other.
How so? Both remove all the existing kids. Neither does anything else.
How do they differ?
They are different because "" is the empty string and null is null. Agreed?
Agreed that "" is the empty string and null is null. I don't see how
that implies anything about the behavior of textContent, on its own.
el.textContent = null won't work consistently across browsers.
Sure it will, if the browsers implement what the spec clearly says to do.
I would argue that it ought to just set the textContent to "null"
That would be a spec change, but yes, the spec could be changed. Except
for that little matter of backwards compat, etc.
The spec you mention makes a misfortunate mistake,
That's not really the subject of discussion here. Given what the DOM
specs say (and which can't be changed), how do we best express that in
IDL in all cases, instead of relying on normative prose? That's the
question on the table.
-Boris
P.S. One thing I should note... the DOM spec is meant to be
language-agnostic. There are plenty of languages in which the Null
value, whatever it is, is an instance of all classes or can be used for
all sorts of types. For example, one can have a NULL char* in C, or a
Null String in Java. The fact that this can't happen in ECMAScript
doesn't mean that the DOM doesn't make use of null DOMStrings. It also
doesn't mean that the null value necessarily needs to be converted to an
ECMAScript string before being passed across language boundaries. But
in practice, a lot of DOM methods define the behavior when passed the
null DOMString as being equivalent to either the behavior when passed ""
or the behavior when passed "null" or the behavior when passed neither.
It would be very useful to have a way to tell these cases apart just
by looking at the IDL, without reading all the prose. I realize your
argument is that we should change all of the DOM to never do anything
"special" with null DOMStrings, simply because ECMAScript doesn't have
such a thing, but that ship sailed long ago when the DOM specs were
decided on and specified in a language-agnostic manner.
