On Aug 26, 2008, at 7:31 PM, Garrett Smith wrote:
Option (a) is unacceptable for the following reasons:
1) It does not match existing implementations and thus would likely
break
compatibility with existing content.
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.
| When it is defined to be null, setting it has no effect.
I think you are misreading the spec. "When it is defined to be null"
is not referring to assigning a value of null. It is referring to
nodeTypes where textContent is null by definition, namely
DOCUMENT_NODE, DOCUMENT_TYPE_NODE and NOTATION_NODE. Your
interpretation does not make sense, because it would make the spec
self-contradictory (it would both say setting to null has no effect,
and describe the particular effect when setting to nul).
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. They are different
because "" is the empty string and null is null. Agreed?
No, the spec requires the identical behavior for both. Please read
again.
el.textContent = null won't work consistently across browsers. I would
argue that it ought to just set the textContent to "null", since it
would make finding the bug easier.
So you are suggesting changing the requirements of the DOM 3 Core
spec, as well as all existing implementations thereof? Such an extreme
move would require extraordinary levels of justification.
Can you explain the reasoning behind your strongly held views on
null used
as a string parameter, since they do not seem to line up with
either the DOM
specifications or with existing implementations? I can sympathize
with a
desire for the handling for null to be clean and elegant, but
unfortunately
existing implementations, content and specs do not allow for such a
possibility.
The spec you mention makes a misfortunate mistake, however, it is not
the mistake that I am concerned with at the moment. The mistakes that
I am more strongly opposed to is the creating of a serialize mapping
of null -> "".
As I have previously stated, it would be inconsistent to serialize
null to something other than "null".
Unfortunately, many DOM methods as specified and widespread DOM
extensions as implemented treat null and "" the same for many string
arguments. It's true that this is inconsistent with the normal rules
of the ECMAScript language.
Because we seek to preserve compatibility with the Web and continuity
with past specifications, the following are not viable options:
- Treating null as the string "null" in cases where it currently is
treated as empty string.
- Raising an exception when null is passed for a parameter that
expects a string, when currently an exception would not be raised.
I think it is a waste of time to discuss these options further, since
neither the Working Group nor implementors will be open to breaking
Web compatibility in this way.
Regards,
Maciej
