W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2008

Re: [selectors-api] Investigating NSResolver Alternatives

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 20 Aug 2008 02:32:56 -0400
Message-ID: <48ABBA98.1000902@mit.edu>
To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
CC: public-webapps <public-webapps@w3.org>

Lachlan Hunt wrote:
> The developers implementing this in Opera has given me feedback saying 
> that this shouldn't throw an exception because JS allows additional 
> arguments to be passed to any method, including other DOM APIs, like 
> getElementById(), etc.  Is there a good reason why this should behave 
> differently?

Well, it depends on whether you plan to add arguments in the future.

If you don't then it doesn't matter that extra arguments don't throw.

But if you do add arguments later, and pages are passing extra arguments 
and expecting that to not throw, then that either constrains what you 
can do with the arguments you add (e.g. they must never throw, no matter 
what) or you force UAs to break pages.

So the suggestion that extra arguments should throw in this case is 
based on the assumption that you plan to add some sort of argument for 
namespaces later and the assumption that throwing on extra arguments now 
is better than the two alternatives in the previous paragraph.

Of course not throwing on extra arguments is indeed the easy path to 
implementation (and is what Gecko will be shipping, it looks like), so 
as long as you can live with the results as a spec writer it's all good 
by me.

Received on Wednesday, 20 August 2008 06:33:39 UTC

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