Garrett Smith wrote:
On Mon, Aug 25, 2008 at 6:07 PM, Jonas Sicking <[EMAIL PROTECTED]> 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
