Re: [WebIDL][Selectors-API] Stringifying null for DOMString attributes and properties

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

Received on Saturday, 7 May 2011 17:37:49 UTC