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

Re: [selectors-api] Investigating NSResolver Alternatives

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 20 Aug 2008 01:00:54 -0700
Message-ID: <48ABCF36.4000301@sicking.cc>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
Cc: Lachlan Hunt <lachlan.hunt@lachy.id.au>, public-webapps <public-webapps@w3.org>

Boris Zbarsky wrote:
> 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.

I think we should follow suite with all other functions in the DOM, 
which means we should not throw for extra arguments. I see no reason to 
treat this function differently than everything else.

/ Jonas
Received on Wednesday, 20 August 2008 08:02:34 UTC

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