On Tue, Aug 26, 2008 at 8:45 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > > 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.
I see. > 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 do not see where the spec describes 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. > I don't see it. Where does it say null is converted to the empty string? I do see some discussion of null being differentiated from empty strings: | 1.3.3 XML Namespaces | In programming languages where empty strings can be | differentiated from null, empty strings, when given as a | namespace URI, are converted to null. | ... | Interface Node | prefix- | Setting the prefix to null makes it unspecified, setting it to | an empty string is implementation dependent. ... | 1.3.6 DOM Features | Note that when using the methods that take a feature and a | version as parameters, applications can use null or empty | string for the version parameter > > >>> 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've explained numerous times that null is not a string value. Treating null as the empty string is not consistent with the language. A method that has special behavior for null would be fine. The special behavior could be throwing an exception (might help find bugs), or creating a string from the argument, in the given language; that would be "null" in EcmaScript and Java. Creating mappings for methods where null=Empty, null="null" is chatty. It's not consistent with what developers would naturally expect in EcmaScript. > I can sympathize with a I would more rather you try to understand the reasoning. I'm putting this one on the list. I've replied to your other (next) message personally. Get some rest. We don't have to come to an agreement right away. Regards, Garrett > Regards, > Maciej > >
