Re: [whatwg] WebIDL and HTML5

Garrett Smith wrote:
> On Mon, Aug 25, 2008 at 6:07 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> Garrett Smith wrote:
>>>>> There are probably others but I can't think of them. I think the
>>>>> majority of the time that strings will want to go to ToString,
>>>>> booleans will want to go to ToBoolean.
>>>> That can be the default, perhaps.  But I suspect usually null should
>>>> become
>>>> "", not "null".
>>> Why?
>>
>> Note that 'null' is generally a valid value for DOMString. This doesn't seem
>> to be explicitly called out in the definition for DOMString. However there
>> are lots of functions that takes a DOMString and describes what to do when
>> the argument is null (as opposed to "null").
>>
>> So for a function like
>>
>>  bool doStuff(in DOMString arg);
>>
> 
> There is no DOM method calld doStuff. Can you provide a concrete
> example? Boris couldn't think of one either. Let us first investigate
> some implementations.

A quick search through the DOM Level 3 Core gives:

The generic statement
# Applications should use the value null as the namespaceURI  parameter
# for methods if they wish to have no namespace. In programming
# languages where empty strings can be differentiated from null, empty
# strings, when given as a namespace URI, are converted to null

So here "" is clearly treated as null, while "null" is distinct from the 
two of them.

Same thing in the hasFeature function which states

# a DOM Level 3 Core implementation who returns true for "Core" with the
# version number "3.0" must also return true for this feature when the
# version number is "2.0", ""  or, null

The function DOMStringList.item returns a DOMString with the value null 
when the index is >= the length. It seems unexpected to return "null" 
here, though it's not explicitly clear.

NameList similarly returns the DOMString null from getName and 
getNamespaceURI under some conditions.

The function DOMImplementation.createDocument accepts null as value for 
namespaceURI and qualifiedName to indicate that no documentElement 
should be created. I would expect that passing "null" for those 
parameters would create an element with localname "null" in the 
namespace "null". Effectively <null xmlns="null"> without the xmlns 
attribute. It further states that an exception should be thrown if 
qualifiedName has a prefix but namespaceURI is null, but seems to allow 
qualifiedName having a prefix and namespaceURI being "null".

The attribute Document.documentURI returns the DOMString null under 
certain conditions. It also states
# No lexical checking is performed when setting this attribute; this
# could result in a null value returned when using Node.baseURI
Which seems to indicate that you can set it to null.

The attribute Document.inputEncoding is of type DOMString and returns 
null under certain conditions.

The attribute Document.xmlEncoding is of type DOMString and returns null 
under certain conditions.

The attribute Document.xmlVersion is of type DOMString and returns null 
under certain conditions.

A lot of functions on the Document interface for creating nodes state 
that nodes are created with "localName, prefix, and namespaceURI set to 
null", such as createElement. All these properties are DOMStrings. 
Further, the namespace-aware functions, such as createElementNS say to 
throw an exception if the qualifiedName parameter has a prefix but 
namespaceURI is null. It makes no such statement if the namespaceURI is 
"null".


I'm actually going to stop here. There are plenty of references in the 
spec to DOMStrings having the value null. So while it's not specifically 
clear in the definition of DOMString it seems clear to me that null is a 
valid value for DOMString. So no conversion using any conversion 
operator is needed. Thus I don't think talking about what ToString does 
is relevant to the discussion.

Further, many of functions in the DOM Level 3 Core spec treat null as 
"", not as "null". All the namespace aware factory functions on the 
Document interface does so, DOMImplementation.hasFeature does so, 
Element.getAttributeNS does so.

>> type of conversion is needed at all. However most functions in the DOM spec
>> does not define behavior for the null value, so we have chosen to treat it
>> as the the empty string as that seems like the most sensible behavior.
> 
> It is not something that can or should be generally relied upon
> because it is not standardized and indeed works differently in
> implementations. Please also review the example I provided earlier,
> assigning an object as a css property value.

In your example, if I understand it correctly, you are passing it 
something that is not a valid DOMString. In that case I absolutely agree 
that using ToString to convert it to a string is the right thing to do.

However when null is passed that is not the case.

/ Jonas

Received on Tuesday, 26 August 2008 07:46:24 UTC