Re: [whatwg] WebIDL and HTML5

On Aug 26, 2008, at 5:22 PM, Garrett Smith wrote:

>
> On Tue, Aug 26, 2008 at 4:47 PM, Jonas Sicking <jonas@sicking.cc>  
> wrote:
>>
>> So let me repeat the question with
>> the grammatical error fixed. Please do excuse any other grammar  
>> errors I
>> introduce as English is a second language to me.
>>
>> 3)  The behavior of the function when null is passed as value for an
>>   argument is almost always either that of "" or that of "null".
>>   Which one depends on the exact DOM method.
>>
>> Do you agree with this?
>>
>
> No, I do not agree. If the parameter type is domstring, and null is
> not allowed, and the caller passes null, then the current behavior is
> implementation-dependent.

1) What DOM methods or attributes are specified to take a DOMString  
but disallow null? At least some DOM methods clearly specify how null  
should be treated when passed as the value for a DOMString parameter.  
There are also many DOM methods and attributes that are not specified  
anywhere (except perhaps in the unstable HTML5 Working Draft), which  
thus currently have implementation-defined behavior. And many other  
methods do not specifically say null is either allowed or disallowed,  
which would lead to the presumption that it is allowed, since the  
specification of other methods assumes it matches the DOMString type.

> I did not agree ever that "" should be used
> when null is passed as a value to an object that expects a string (or
> dom method that expects a domstring). I believe that in the
> following:-
>
>
> el.textContent = null;
>
> - with the options:-
> a) raise exception
> b) textContent is set to "null"
> c) textContent is set to ""
>
> Option (c) is wrong.
> Option (b) would be marginally useful in a few cases
> Option (a) would be helpful in some cases (finding bugs)

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"?


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.


Regards,
Maciej

Received on Wednesday, 27 August 2008 01:53:02 UTC