- From: John Resig <jeresig@gmail.com>
- Date: Thu, 19 Feb 2009 17:26:33 -0500
- 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 UTC