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

Re: [selectors-api] Stringifying undefined

From: John Resig <jeresig@gmail.com>
Date: Thu, 19 Feb 2009 17:26:33 -0500
Message-ID: <730bab940902191426n7c480e0q79e9697eef9bd517@mail.gmail.com>
To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Cc: Jonas Sicking <jonas@sicking.cc>, Rune Lillesveen <rune@opera.com>, WebApps WG <public-webapps@w3.org>
The test suite has been updated accordingly:
http://ejohn.org/apps/selectortest/

http://github.com/jeresig/selectortest/commit/4827dedddaea6fa0b70cfdaadeeafef0d732a753

--John



On Thu, Feb 19, 2009 at 6:40 AM, Lachlan Hunt <lachlan.hunt@lachy.id.au> wrote:
> Jonas Sicking wrote:
>>
>> On Wed, Feb 18, 2009 at 7:34 AM, Anne van Kesteren <annevk@opera.com>
>> wrote:
>>>
>>> So ideally what we do here is simply in line with how we plan to make all
>>> APIs that accept strings work (with exceptions).
>>
>> Yup, that's exactly what I've been arguing (both for this and for
>> other APIs). I think we should not have [Null=...] or [Undefined=...]
>> in there at all for now. Instead put some wording in that says that
>> we're doing whatever the default is for WebIDL, but that that isn't
>> fully locked down as of yet (since the spec is still a WD).
>
> I have now removed both the [Null] and [Undefined] extended attributes from
> the IDL and added a note advising implementers that WebIDL defines how to
> handle null and undefined.
>
> http://dev.w3.org/2006/webapi/selectors-api/#nodeselector
>
> Given the current WebIDL draft, this means they stringify to "null" and
> "undefined", respectively.
>
> --
> Lachlan Hunt - Opera Software
> http://lachy.id.au/
> http://www.opera.com/
>
>
Received on Thursday, 19 February 2009 22:27:09 GMT

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