Re: [whatwg] WebIDL and HTML5

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

Received on Wednesday, 27 August 2008 03:46:10 UTC