- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 13 Jan 2009 16:10:33 -0800
On Tue, Jan 13, 2009 at 3:37 PM, Cameron McCormack <cam at mcc.id.au> wrote:
> Jonas Sicking:
>> I talked with Cameron a while ago about what the default behavior
>> should be for null. We couldn't find any functions that required that
>> null be treated as "null", but there are several examples of functions
>> that require that null be treated as the empty string.
>
> I began testing all attributes and operations with DOMString arguments
> from a selection of specs for their behaviour wrt null and undefined:
>
> http://mcc.id.au/2009/01/string-handling/string-handling
>
> Each pair of characters in the column for a browser is the behaviour for
> null and undefined, respectively. It's nowhere near complete, though
> you can see that there are some operations arguments and attributes that
> stringify null to "null" ("S" in the column).
So in the null column an "S" means that it's treated as "null", an "E"
as "", but what does "N" mean?
Yes, there are definitely a lot of "S"s in the null column for
non-firefox browsers. The question to me is if this is really needed
for webcompat though. Looking though our bug database I see no
indication of that, but that's not necessarily a proof.
If we were able to use "" as the default behavior for null then we
would be able to get away with much fewer exceptions (so far alert()
and and possibly write() has been found).
/ Jonas
Received on Tuesday, 13 January 2009 16:10:33 UTC