W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

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

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Sat, 07 May 2011 13:37:20 -0400
Message-ID: <4DC58350.3020601@mit.edu>
To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
CC: public-webapps@w3.org
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.

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

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:31 UTC