[whatwg] WebIDL and HTML5

[Garrett]

On Tue, May 6, 2008 at 4:04 AM, Ian Hickson <ian@...> wrote:

>
> heycam -- see at the end for a request for WebIDL.
>
> On Mon, 25 Apr 2005, Brad Neuberg wrote:
>>
>> True, but having prototypes on DOM objects can be extremely useful and
>> provide all sorts of very powerful options.  Mozilla allows manipulation
>> of the prototype object on DOM objects (except for removing the original
>> native methods and attributes, for security reasons).  Unfortunately, IE
>> doesn't support this, so this ability can't really be used in practice.
>

Nor should it be. For any environment. It is a good way to create bugs
and confuse programmers. Anyone who says that this is "misfortunate"
ought to say why he thinks this is so.

> WebIDL now requires this.
>

Requires what?

>
> On Thu, 11 May 2006, Dean Edwards wrote:
>>
>> At the moment, DOM objects are specified in a language neutral way.
>> That's fine. However, this makes these objects uninteresting and
>> cumbersome to script with.
>>
>> Mozilla has a more integrated programming environment. It exposes DOM
>> objects as native JavaScript objects. That means I can do things this
>> like this:
>>
>> Object.prototype.foo = "bar";
>> alert(document.body.foo);
>>
>> ==> "bar"
>>
>> A trivial example but it demonstrates that the DOM and JavaScript are
>> not totally separate on a Mozilla platform. This is very cool. 8-)
>
> WebIDL now requires this.
>

Can you elaborate on that statement?

>
>> It would be great if NodeLists were subclasses of JavaScript Array

It wouldn't really make sense to do that.

>> objects (especially with the introduction of Mozilla's Array Extras
>> [1]). This makes iteration over DOM queries more flexible.
>

No, it doesn't. What are you trying to accomplish?

> You can assign the Array methods to the NodeList prototype, they're
> generic.
>

Was there any thought that went into that statement?

This is horrible advice for several reasons:

1) Modifying host objects with new properties is a good way to create
bugs and confuse developers.
2) NodeList is an interface and should not have any implementation.
Even in browsers that expose a NodeList object, it cannot be
guaranteed
3) You answered a question for which no need was demonstrated, and
provided no example.
4) Calling any of the array methods on a NodeList would obviously
fail. We can take a look at push, for example:-

javascript:try{ alert(Array.prototype.push.call(document.childNodes));
} catch(ex){alert(ex.message);}

Should err out in step 7 of push attempting to set the "length" property.

| 15.4.4.7  Array.prototype.push([ item1[, item2 [,...]]])
|
|   The arguments are appended to the end of the array,
| in the order in which they appear. The new length of the array
| is returned as the result of the call.
|
|   When the push method is called with zero or more arguments
| item1, item2, etc., the following steps are taken:
|
| 1. Call the [[Get]] method of this object with argument "length".
| 2. Let n be the result of calling ToUint32(Result(1)).
| 3. Get the next argument in the argument list; if there are no more
|arguments, go to step 7.
| 4. Call the [[Put]] method of this object with arguments ToString(n)
|and Result(3).
| 5. Increase n by 1.
| 6. Go to step 3.
| 7. Call the [[Put]] method of this object with arguments "length"
|and n.
| 8. Return n.

We could also see how easily [[put]] method would not work as Array
[[Put]]. For example, setting a "2" property:-
javascript:alert(document.childNodes[2] = 1);

will add a new property with name "2"
javascript:alert(document.childNodes[2]);

and will not update the length.

javascript:alert(document.childNodes.length);

Modifying host objects is a very bad idea. NodeList is an Interface.
An interface should have no implementation. Even if you really wanted
to follow Ian's advice, it wouldn't work.

This is probably what led up to the dojo.NodeList and may have
influenced Ian in his Web Forms 2.0. Modifying NodeList.prototype is
not advisable.

(more top posts)

>
> On Sun, 21 May 2006, Dave Hodder wrote:

[snip]

More...

> On Sat, 2 Jun 2007, Anne van Kesteren wrote:
>>
>> For .innerHTML = null Opera and Internet Explorer act as if the literal
>> string "null" was used. Firefox acts as if "" was used.
>>
>> For .innerHTML = undefined Opera, Firefox and Internet Explorer act as
>> if the literal string "undefined" was used.
>
> On Mon, 4 Jun 2007, Jonas Sicking wrote:
>>
>> I'd really dislike having to have this one property behave differently
>> than other text properties in the DOM. How do opera/ie deal with other
>> text properties like .src, .id, .textContent?
>
> On Mon, 4 Jun 2007, Michael A. Puls II wrote:
>>
>> For .src and .id, IE and Opera set "null".
>> Opera does the same for textContent.
>>
>> For .src, this obviously means that IE and Opera will then return the
>> directory of the page + "null" where as FF will return the URI to the
>> page.
>>
>> The way IE and Opera do "null" doesn't seem to be just limited to
>> innerHTML.
>
> On Tue, 5 Jun 2007, liorean wrote:
>>
>> Seems to me like they are simply using the ECMAScript ToString
>> algorithm, unless I'm mistaken. That's probably a good thing to specify
>> for this, too.
>

I agree. We can see that IE does not always.

javascript:void(document.body.style.color = { toString: function()  {
return "#900"; } })

Won't take that ToString to call the objects' toString.

I agree that this should be specified.

> On Mon, 4 Jun 2007, Maciej Stachowiak wrote:
>>
>> I think DOM properties (and sometimes methods and function arguments)
>> vary on this. Some use the raw ECMAScript ToString algorithm. Others
>> additionally map the null value to the empty string instead of "null".
>> Still others map the undefined value to "undefined".

undefined -> "undefined" would be the ToString algorithm. Please
see section 9.2.

>
> I think what we need is for WebIDL to have annotations for these cases,

Why?

A simple call to ToString for setting string values is all that needs
to be said.

> which can be prefixed in front of any occurance of "DOMString" in any IDL
> block, and then we can work down the APIs and check each DOMString
> occurance and work out which the UAs are doing. Say:
>
>   [Null=Null, Undefined=Null]
>   [Null=Null, Undefined=Empty]
>   [Null=Empty, Undefined=Empty]
>   [Null=Null, Undefined=String]
>   [Null=Empty, Undefined=String]
>   [Null=String, Undefined=String]
>
> ...so that we can do, e.g.:
>
>   Window open([Null=String, Undefined=String] in DOMString url,
>               [Null=String, Undefined=Empty] in DOMString name,
>               [Null=Empty, Undefined=Empty] in DOMString features);
>
> ...or whatever is appropriate.
>

Why such complexities?

Garrett

> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL

[Boris Zbarsky]

Garrett Smith wrote:

>>   [Null=Null, Undefined=Null]
>>   [Null=Null, Undefined=Empty]
>>   [Null=Empty, Undefined=Empty]
>>   [Null=Null, Undefined=String]
>>   [Null=Empty, Undefined=String]
>>   [Null=String, Undefined=String]
>>
>> ...so that we can do, e.g.:
>>
>>   Window open([Null=String, Undefined=String] in DOMString url,
>>               [Null=String, Undefined=Empty] in DOMString name,
>>               [Null=Empty, Undefined=Empty] in DOMString features);
>>
>> ...or whatever is appropriate.
>
> Why such complexities?

Because existing implementations sometimes treat null as meaning empty
string and sometimes as meaning the string "null" and sometimes as
meaning a special value that is not actually quite the same as the empty
string.  Note that some of this is required by some existing specifications.

Similar for undefined.

Expressing that in the IDL requires the above setup, unless you have a
better proposal?

-Boris

[Garrett]

On Mon, Aug 25, 2008 at 8:02 AM, Boris Zbarsky <bzbarsky@...> wrote:

> Garrett Smith wrote:
>>>
>>>  [Null=Null, Undefined=Null]
>>>  [Null=Null, Undefined=Empty]
>>>  [Null=Empty, Undefined=Empty]
>>>  [Null=Null, Undefined=String]
>>>  [Null=Empty, Undefined=String]
>>>  [Null=String, Undefined=String]
>>>
>>> ...so that we can do, e.g.:
>>>
>>>  Window open([Null=String, Undefined=String] in DOMString url,
>>>              [Null=String, Undefined=Empty] in DOMString name,
>>>              [Null=Empty, Undefined=Empty] in DOMString features);
>>>
>>> ...or whatever is appropriate.
>>
>> Why such complexities?
>
> Because existing implementations sometimes treat null as meaning empty
> string and sometimes as meaning the string "null" and sometimes as meaning a
> special value that is not actually quite the same as the empty string.  Note
> that some of this is required by some existing specifications.
>
> Similar for undefined.
>
> Expressing that in the IDL requires the above setup, unless you have a
> better proposal?
>

I already expressed my opinion, agreeing with Liorean. For domstring
arguments, call the internal ToString on the input would be the
general rule, unless otherwise stated. This would seem to cover the
majority of cases.

| I agree. We can see that IE does not always.
|
| javascript:void(document.body.style.color = { toString: function()
| { return "#900"; } })


> -Boris
>

[Boris Zbarsky]

Garrett Smith wrote:
> I already expressed my opinion, agreeing with Liorean. For domstring
> arguments, call the internal ToString on the input would be the
> general rule, unless otherwise stated. This would seem to cover the
> majority of cases.

window.open is one of the cases when things are not covered, and that's
what we were talking about, no?

-Boris

[Garrett]

On Mon, Aug 25, 2008 at 10:20 AM, Boris Zbarsky <bzbarsky@...> wrote:

> Garrett Smith wrote:
>>
>> I already expressed my opinion, agreeing with Liorean. For domstring
>> arguments, call the internal ToString on the input would be the
>> general rule, unless otherwise stated. This would seem to cover the
>> majority of cases.
>
> window.open is one of the cases when things are not covered, and that's what
> we were talking about, no?
>

That's the example Ian posted up. I think Ian may be a bit off in his
observations. undefined and null don't convert to the empty string in
window.open.

For example:-

window.open();

If the first argument is null or undefined or the empty string, no uri
is loaded and an blank/empty window is displayed. There seems to be no
mapping though Ian has requested documenting such mapping.

Are there other examples for "if the argument is null or undefined..."?

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.

I can see no reason for special-casing innerHTML = null.. Any
application that uses such technique is arguably already broken.

Garrett

> -Boris
>

[Boris Zbarsky]

Garrett Smith wrote:
> window.open();

Which should be equivalent to window.open(undefined) (and isn't in some
UAs), right?

What should window.open(null) do?

> If the first argument is null or undefined or the empty string, no uri
> is loaded and an blank/empty window is displayed.

This is not the case in Firefox, Opera, or Safari.  Safari and Firefox
treat null as "null".  Opera treats it as "".  Opera treats undefined as
"", while Safari and Firefox treat it as "undefined".

This is for window.open's first argument.

> There seems to be no mapping though Ian has requested documenting such mapping.

No mapping of what?  ""+null is "null".  ""+undefined is "undefined".
Those are basically what Firefox and Safari do.  That doesn't seem like
the right thing to do here, necessarily.

> Are there other examples for "if the argument is null or undefined..."?

Sure.  A lot of the namespace-relatd DOM methods, as well as all sorts
of DOM0 stuff.

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

-Boris

[Garrett]

On Mon, Aug 25, 2008 at 11:28 AM, Boris Zbarsky <bzbarsky@...> wrote:

> Garrett Smith wrote:
>>
>> window.open();
>
> Which should be equivalent to window.open(undefined) (and isn't in some
> UAs), right?
>
> What should window.open(null) do?
>
>> If the first argument is null or undefined or the empty string, no uri
>> is loaded and an blank/empty window is displayed.
>
> This is not the case in Firefox, Opera, or Safari.  Safari and Firefox treat
> null as "null".  Opera treats it as "".  Opera treats undefined as "", while
> Safari and Firefox treat it as "undefined".
>
> This is for window.open's first argument.
>
>> There seems to be no mapping though Ian has requested documenting such
>> mapping.
>
> No mapping of what?  ""+null is "null".  ""+undefined is "undefined".

The addition operator results in concatenation when either operand is
a string. This results in a calls to the internal ToString, which is
what I'm suggesting should be the general rule.

> Those
> are basically what Firefox and Safari do. That doesn't seem like the right
> thing to do here, necessarily.
>

I agree that loading path + '/null' or path + 'undefined' is not
desirable. Any application that relies on this is already broken,
arguably, because, contrary to your observations, safari first checks
to see if the argument is null or undefined or the empty string, and,
if that is true, then no uri is loaded. Example:

<!DOCTYPE HTML>
<html lang="en">
<head>
        <title>window.open()</title>
</head>
<body>
<a href="javascript:void(window.open());">open()</a>
<a href="javascript:void(window.open(null));">open(null)</a>
<a href="javascript:void(window.open(undefined));">open(undefined)</a>
<a href="javascript:void(window.open(0));">open(0)</a>
</body>
</html>

Result in Safari:

 window.open(0), loads "can't find that page".
 all others load blank window

Result in Firefox:
 open() open('') open blank window
 all others load "can't find that page"

Ian and others, you may use this and any other test case I post up.

>> Are there other examples for "if the argument is null or undefined..."?
>
> Sure.  A lot of the namespace-relatd DOM methods, as well as all sorts of
> DOM0 stuff.
>
>> 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?

Garrett
> -Boris
>

[Boris Zbarsky]

Garrett Smith wrote:
> The addition operator results in concatenation when either operand is
> a string. This results in a calls to the internal ToString, which is
> what I'm suggesting should be the general rule.

All I'm saying is that this will require annotating a very large number
of API methods; possibly larger than an alternate general rule.

> I agree that loading path + '/null' or path + 'undefined' is not
> desirable. Any application that relies on this is already broken,
> arguably, because, contrary to your observations, safari first checks
> to see if the argument is null or undefined or the empty string

Indeed.  I mixed up Safari and Opera in my test.  So Opera does
undefined -> "undefined" and null -> "null" for the first arg of
window.open, while safari treats them as empty strings.

>> That can be the default, perhaps.  But I suspect usually null should become
>> "", not "null".
>
> Why?

Honestly?  Because that's what Firefox does right now, except in certain
special cases (window.open being one of them, actually), and things
aren't breaking?  Unless other UAs are doing other things (and hence
sites just don't rely on any particular behavior at all), this seems to
indicate that web compat lies on the side of treating null as "".

-Boris

[Jonas Sicking-2]

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);

if null is passed there should be no need to call .toString() or any
other 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.

/ Jonas

[Garrett]

On Mon, Aug 25, 2008 at 12:47 PM, Boris Zbarsky <bzbarsky@...> wrote:

> Garrett Smith wrote:
>>
>> The addition operator results in concatenation when either operand is
>> a string. This results in a calls to the internal ToString, which is
>> what I'm suggesting should be the general rule.
>
> All I'm saying is that this will require annotating a very large number of
> API methods; possibly larger than an alternate general rule.
>
>> I agree that loading path + '/null' or path + 'undefined' is not
>> desirable. Any application that relies on this is already broken,
>> arguably, because, contrary to your observations, safari first checks
>> to see if the argument is null or undefined or the empty string
>
> Indeed.  I mixed up Safari and Opera in my test.  So Opera does undefined ->
> "undefined" and null -> "null" for the first arg of window.open, while
> safari treats them as empty strings.
>
>>> That can be the default, perhaps.  But I suspect usually null should
>>> become
>>> "", not "null".
>>
>> Why?
>
> Honestly?  Because that's what Firefox does right now, except in certain

That is not true. Firefox has Spidermonkey. Spidermonkey follows
Ecma-262r3, section 9.2.

| 9.8 ToString
| The operator ToString converts its argument to a value of
| type String according to the following table:
|
|Input Type        Result
| Undefined        "undefined"
| Null             "null"

> special cases (window.open being one of them, actually), and things aren't
> breaking?  Unless other UAs are doing other things (and hence sites just
> don't rely on any particular behavior at this seems to indicate that
> web compat lies on the side of treating null as "".
>

Web sites that rely on window.open(null) are already broken. They are
broken because they are relying on non-specified behavior that will
have different results in different browsers.

Firefox' 3.1 (Minefield) implementation window.open() produces a
different result as window.open(undefined). There is no standard for
this, so it is not invalid, however, it is inconsistent with 10.1.3
Ecma-262 r3 (which applies to built-in methods), and somewhat against
the nature of the language. Firefox' behavior should probably be
changed exactly to match what I wrote earlier, and this can be
specified (what Safari does is that if the argument is null,
undefined, or the empty string, a blank window opens). There is no
mapping of null -> "".

Garrett

> -Boris
>
>

[Garrett]

On Mon, Aug 25, 2008 at 6:07 PM, Jonas Sicking <jonas@...> 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.


> if null is passed there should be no need to call .toString() or any other

No, but there should be a need to call ToString.

> 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.

Considering your argument for serializing null -> "" being the most
"sensible", I disagree. Ecma-262 r3, Section 9.8 ToString states
clearly that null is mapped to "null". This is how the language was
designed. I do not agree that it's a "bug" or mistake.

We've been over that before. Here:
http://lists.w3.org/Archives/Public/public-webapi/2008May/0457.html

Garrett

> / Jonas
>

[Jonas Sicking-2]

Garrett Smith wrote:

> On Mon, Aug 25, 2008 at 6:07 PM, Jonas Sicking <jonas@...> 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

[Cameron McCormack-4]

Jonas Sicking:
> 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.

The fact that DOMString has been defined as a boxed valuetype in the DOM
Core IDL is what allows a null value, as I understand it.

--
Cameron McCormack ≝ http://mcc.id.au/

[Boris Zbarsky]

Garrett Smith wrote:
>>>> That can be the default, perhaps.  But I suspect usually null should
>>>> become
>>>> "", not "null".
>>> Why?
>> Honestly?  Because that's what Firefox does right now, except in certain
>
> That is not true. Firefox has Spidermonkey.

The Spidermonkey part is irrelevant for purposes of this discussion,
except in places where JS_ValueToString is used (basically DOM0
special-cases).  What matters is the XPConnect glue layer which converts
JS function calls into C++ function calls in the general case.

In fact, the relevant code for Gecko 1.9 is right here:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/xpconnect/src/xpcconvert.cpp&rev=1.129&mark=743-751#731

and

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/xpconnect/src/xpcprivate.h&rev=1.283&mark=932-934#922

It converts a JSVAL_NULL into an empty nsAString with the IS_VOID bit set.

> Firefox' 3.1 (Minefield) implementation window.open() produces a
> different result as window.open(undefined).

Indeed, because the latter goes through XPconnect, which converts
undefined to "undefined" for some odd reason.

-Boris

[Boris Zbarsky]

Garrett Smith wrote:
> There is no DOM method calld doStuff. Can you provide a concrete
> example? Boris couldn't think of one either.

Uh, what?  You never said, "I don't understand that this applies to all
DOM methods that take a DOMString, so I'd like to have some specific
examples."

In any case, here's a simple example:

javascript:try { alert(document.createElement(null).localName); }
catch(e) { alert(e) }

In some UAs that alerts "null", in some it throws an exception because
createElement("") is not valid.  Just try it.

> No, but there should be a need to call ToString.

The thing is, ToString is lossy.  Once called, there is no way to tell
apart "null" and null.  However, there are DOM methods which require
different behavior for the two (e.g. createElementNS and so forth, which
I did explicitly mention earlier, contrary to your "counldn't think of
one either" business).

Similarly, there are DOM methods that require different behavior for
null and "".  Specific examples include the proposed DOM style set APIs,
DOMImplementation.createDocument. There are also cases where returning
null and returning "" are not equivalent.  inputEncoding is an example.

> It is not something that can or should be generally relied upon
> because it is not standardized and indeed works differently in
> implementations.

Yes.  The whole point is to standardize it.

> Considering your argument for serializing null -> "" being the most
> "sensible", I disagree.

It's sensible in the context of the large number of DOM methods that
treat the two as equivalent (again, all the *NS methods in DOM3 Core).

-Boris

[Garrett]

On Tue, Aug 26, 2008 at 5:38 AM, Boris Zbarsky <bzbarsky@...> wrote:
> Garrett Smith wrote:
>>
>> There is no DOM method calld doStuff. Can you provide a concrete
>> example? Boris couldn't think of one either.
>
> Uh, what?  You never said, "I don't understand that this applies to all DOM
> methods that take a DOMString, so I'd like to have some specific examples."
>

I did ask. Here's what I wrote:

| Are there other examples for "if the argument is null or
| undefined..."?
|
| 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.

> In any case, here's a simple example:
>
> javascript:try { alert(document.createElement(null).localName); } catch(e) {
> alert(e) }
>
> In some UAs that alerts "null", in some it throws an exception because
> createElement("") is not valid.  Just try it.
>

Using ToString, the following result would be obtained:

// ERROR
document.createElement("");

// create a "<null>" element.
document.createElement(null);

// Create an "<a>" element.
document.createElement( { toString: function(){ return "a"; }} );

document.createElement( new String("div") );

To simulate the ToString effect, use String( arg ); (do not use new
String(arg));

>> No, but there should be a need to call ToString.
>
> The thing is, ToString is lossy.  Once called, there is no way to tell apart
> "null" and null.  However, there are DOM methods which require different
> behavior for the two (e.g. createElementNS and so forth, which I did
> explicitly mention earlier, contrary to your "counldn't think of one either"
> business).


After the method createElement(null) is called, there will be no need
to tell apart null and "null". I see that. Why is that a problem?

You said that null -> "null" is "lossy". I don't think that's a valid
argument. null -> "" is even more "lossy".

>
> Similarly, there are DOM methods that require different behavior for null
> and "".  Specific examples include the proposed DOM style set APIs,
> DOMImplementation.createDocument. There are also cases where returning null
> and returning "" are not equivalent.  inputEncoding is an example.
>

null and "" are not equivalent. Setting a style to have the value null
should probably convert the value to "null"

document.body.style.color = null;

However, such applications that are already expecting such behavior
are already broken because they are relying on non-standard behavior
which is known to not work cross-browser. Setting style values to
invalid values will result in script errors in Internet Explorer.

document.body.style.color == "null"

Internet Explorer is more strict in that it requires a string value,
and won't call ToString. It would be useful to have the method call
ToString, because that way an object with a toString method could be
used for setting values:

<script>
var colorObject = {
  r : 16, g: 255, b: 16,
  toString : function() {
    return "rgb(" + this.r + "," + this.g + "," + this.b+")"; }
}

document.body.style.backgroundColor = colorObject;
</script>

It would seem somewhat expected that the colorObject's toString would
be called