W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

Re: Call for Consensus - Selectors API to Candidate Rec

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 12 Feb 2009 11:50:24 -0800
Message-ID: <63df84f0902121150xe52318fv52e7eb6062796fd5@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Lachlan Hunt <lachlan.hunt@lachy.id.au>, WebApps WG <public-webapps@w3.org>

On Thu, Feb 12, 2009 at 8:14 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>
> Lachlan Hunt wrote:
>>
>> Firefox appears to have some issues that might related to the API, though
>> I haven't investigated the cause of those yet, so I don't know for sure.
>
> On John Resig's tests in particular, every single failure in Gecko is due to
> a violation of this part of the API:
>
>  Undefined=Empty
>
> This is using a WebIDL syntax from a working draft that we don't implement
> yet, and the current JavaScript DOM binding in Gecko always converts
> undefined in parameters to the string "undefined".
>
> If this part of WebIDL is stable, we can go ahead and implement it, but I
> see no obvious evidence of that from the WebIDL working draft.

Out of curiosity, are there any other methods in the DOM that treat
undefined as the empty string? If not, is there really a reason to
make these two functions different?

An alternative would be to not mention behavior for undefined at all
and let it be whatever the default is for WebIDL once that spec makes
up its mind. It seems more important to me to behave consistently with
other methods than to have any specific behavior for undefined.

/ Jonas
Received on Thursday, 12 February 2009 19:51:04 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:30 GMT