Re: [whatwg] WebIDL and HTML5

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.

Received on Wednesday, 27 August 2008 03:14:37 UTC