On 5/7/11 10:03 AM, Lachlan Hunt wrote:
For document.write(), Gecko, Webkit (including Safari 5), Opera and IE
write "null" on both Windows and Mac. I don't know which version of
Safari you were using that gave you a different result.
I was using Safari 5 on Mac; looks like it does something weird with
document.write from a javascript: URI that's unrelated to the handling
of null.
There are various other cases that have this behavior. In Gecko,
anything that goes through JS_ValueToString (instead of default
XPConnect argument conversion that converts null to a void empt) will do
this. This is unfortunately not particularly consistent.
Is there any reason to believe that any or all of those are
intentionally done that way for this handling of null, or are they
merely a result of the way the programmers arbitrarily decided to
implement them?
For the cases I describe above, the latter.
Furthermore, some IDL in Gecko explicitly treats null as "null". In
addition to the selector API, there's createHTMLDocument,
Opera throws an exception when invoking createHTMLDocument(null). Is
there any evidence that stringifying to "null" is required for
compatibility at all?
No idea.
.text on HTMLAnchorElement,
a.text is defined as an alias for a.textContent in HTML, which does
stringify null to "" in all implementations.
I'm just saying that in Gecko it's not an alias at the moment.
Is there any reason why .text and .textContent need to be
handled differently?
No idea.
-Boris
