W3C home > Mailing lists > Public > public-webapi@w3.org > March 2006

Re: ACTION-87: Selectors API

From: Robin Berjon <robin.berjon@expway.fr>
Date: Wed, 22 Mar 2006 23:01:41 +0100
Message-Id: <86E1386A-A973-4AAE-AEF5-A91704E1B14C@expway.fr>
Cc: "Web APIs WG (public)" <public-webapi@w3.org>
To: Maciej Stachowiak <mjs@apple.com>

On Mar 22, 2006, at 20:25, Maciej Stachowiak wrote:
> On Mar 22, 2006, at 2:30 AM, Anne van Kesteren wrote:
>>> * IMHO the method should not raise an exception when the selector  
>>> contains a pseudo-element. It should would return an empty list.
>> Given that it per definition only returns Element nodes I don't  
>> see why it shouldn't raise an exception.
> I think exceptions should be reserved for actual syntax errors, not  
> for selectors that can't match an element. I'm sure there are other  
> ways besides pseudo-elements to make a selector that can't match  
> anything.

I'm not convinced that an exception is the best way to go, but being  
able to make the difference between the inability to process the  
request and the fact that nothing matched could prove important for  
versioning purposes. For instance say v2 supports the ability to  
return the first-letter inside an element while v1 doesn't, and I  
want to write code that tries to do that using selectors in such a  
way that if the implementation tells me it's impossible I fall back  
to some hand-coded munging.

If we can't differentiate we'll have to resort to hasFeature(). Quite  
frankly, give me exceptions any day over that :)

Robin Berjon
    Senior Research Scientist
    Expway, http://expway.com/
Received on Wednesday, 22 March 2006 22:01:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:20 UTC